Editor's note: These minutes have not been edited. DRUMS Notes Reported by M. Wall Review of Agenda (slight rearrangements) Quick discussion of charter, no revision Pete Resnick is now the 822 revision author milestones updated John Klensin's list of open issues on 821 comment many are difficult to resolve issues 1. 821 has the feature that it goes through spec three times -- overview, description of how it works, then listing of how things work; redundant in some ways, not complete in others comment: overview isn't really an overview, we need a real overview -- 1 pagerunthrough of how protocol works john K. wanted to punt to someone else for language writing discussion of whether this should be the simplest case, or include pointers to more complicated cases. Paul Hoffman (?) volunteered to take a shot at doing this overview part. discussion about where to put examples -- at end of document, separate, etc. some concern people would code from examples several folks suggested in-line examples are very helpful at making the document clear (JK has not changed examples at all) suggestion to standardize addresses, domains used in examples the relative merits of whether to use real addresses or not were kicked around -- it's a problem if it's an existing domain because then when somebody sends messages to the example. JK will preserve existing model but include a footnote that they are bogus addresses. 2. Tutorial document on current practices with SMTP -- no volunteer yet to write this 3. state table diagrams not as popular as they were when 821 was written JK proposes simply removing them several comments they don't help, document is pretty big already comment state table used to verify work done; may be useful to some if question is right or wrong, they may be better taken out consensus many were wrong, misleading decision to dump them rather than trying to fix them was reached. 4. Verify and expansion JK seeks advice from WG about what to do about these things been a suggestion to repeal the requirement in 1123 to support invitations to verify comment: legislating implementation issues that are not visible from the network -- you must implement, but you may or may not have a configurable option to let the user turn this off-- is a problem response: this is technically long, as it is detectable on the wire via a different error code suggestion: to make language recommendation-oriented, not must or should two responses: I haven't implemented this, or my user has turned this off; just require these be semantically correct, not required per se response: it's a security problem potentially, why worry about this particular distinction? response: can be used as a debugging aid; with nothing, no option to figure this out response: suggest no change, several agree - on the wire clarification: two responses are command not implemented, cannot verify user but will accept message and attempt delivery; when turned off, the latter message is used attempt to call consensus: verify is no longer a must (a few exceptions)?? additional discussion ensues comment: as soon as allow implementations to turn them off, they tend to do it to save time and money. removes usefulness of requirements. if spec says X and vendor doesn't do X, you can complain if it says X is optional, harder to use conformance hammer consensus: retain verify as a must, status quo verbal tidying up only JK will take another look at text surrounding error messages, solicited comments on preferred text Spamming problem with expand (note -- perhaps digressive-- about use of expand to crack mailing lists; use of expand to figure out who's using the list is useful administratively.) JK will add notes about spamming implications with SMTP server implementations suggestion that it be recommended that site admins. turn this on and off as needed for local admin suggestion to name section 3.5 debugging commands -- not intended to be general fodder of protocol -- don't want a "verify receipt" before every command comment: should either say commands return addresses or not agreed to clean up text this way to indicate verify can return non-address text 5. sourceroutes MTA that supports them permitted to follow them or to strip it left ambigious question that if you follow a sourceroute as to wehther or not the reverse path was to be copied these two must be clarified suggestion to continue 1123 directio, simply rquire ignore sourceroutes to comply with specification -- direction is to simply strip it, follow address on right hand side of @ sign comment sourcerouting is useful for debugging disagreement: sourceroute ends eventually, only useful if it's actually working reply: exampleof email mailing list firewall, need a way to get to mailing lists on either side - sourceroute is a way of getting to it. % hack one way around this. reply: IP literals serves purpose of getting around broken MX records? reply: no, not a good idea to recommend it! response: extended left-side semantics well-enough available, should allow use of default mechanism response: effectiveness of left-hand side hacks not very great, not a high success rate reply: near-hits are often good enough, sourcerouting effective example, shaky local admin, in order to get things through you have to try approximate routing; as internet expands to less cluefully run places, situation continues to exist reply: current spec says % cannot be relied on -- effectively we've killed it anyway, why not just make the core spec as simple as possible, let's just yank it to simplify official mechanisms? response: if cannot forbid the mechanism, have to allow it; make one a should, the other one a may comment: 1989 work was very anti-sourceroute, attempt to kill it off back then; now is finally time to deprecate completely; additional comment about problems with parsing, for example !. Left hand side of @ sign is a local matter. response: can't make it illegal for curret routers, but don't have to make them compliant with the new spec; don't want to open door of complexity of parsing left-hand side, dangerous to essentially re-create facility reply: can't prevent people from doing X, but can provide good core official documents -- this is a prime opportunity to simplify the spec question about implication on return-path? answer: no impact, separate issue comment: current documents require sticking host in return path; can't removeall references to sourcroutes suggestion: change language about return paths and sourceroutes be explicit about what you hae to do with paths so it's easy to make into code reply: don't need arbitrary mechanism in sourceroute, return-path is what you need and all you need issue: need to clarify what should be happening to mail from a certain site sent by sourceroute consensus; don't stick things in return path, no consensus on sourceroutes, will be punted back to list. Sourceroutes no longer required in return path! "New implementations must not" 6. canonical names 1123 appears to specify some names can only appear in certain contexts do we want only resolvable names? [couldn't understand what jK was saying -- literally could not hear] comment: essential that cnames be allowed, things can break, can't avoid everything that breaks distinction between user-allowable and what travels over the wire -- cname or canonical name of the host there is divergent practice in the use of cnames - one case to point to renamed host - useful for migration from one hostname to another, one host to another; other examples of where it is very useful for routing. what goes over the wire is a separate question. must make it clear in document what kinds of things an MTA is expected to deal with -- prescribe behavior with DNS and MX records. response: host table -- official name of host, with nicknames, this was a convenience. official name was what machine emitted on its mail, all references intended to resolve to a host -- cname records are set up this way. comment: current practice for at least one major smtp to not look at official hostnames; real problem to make standard to require them to not deal with cnames response: impossible for a receiving MTA to find out official host given current use of cnames comment: only correct way for a host to find out if something sent is targeted at a particular host is to check against its own IP address; somebody once had claimed their address was 'localhost.domain' and caused a loop because of the IP mapping. Must not try to send this along. comment: way people want to write to the host is actually important information comment: two issues: private vs. public, official vs. unofficial cnames *are* official names, multiple names that need to be respected; cannot have a rule that alters the name. Like alias files -- personal vs. system alias. we should simply treat cnames as oficial names and not alter them. reply: load on DNS, also complicates configuration of mail systems comment: cname confusing, because which "side" of cname record that's used is not clear. Useful to have both cases of usage of both sides. reply: cnames are simply aliases for canonical name. reply: no longer have sense that mailhost and maildomain at the same thing. reply: there is no way anymore to say that this is *the* name of the host. reply: end-users key, large number of hosts with large number of cnames pointing to them -- literally hundreds of cnames pointing to them -- a silly restriction on what's working now with cnames getting passed allthe way through reply: this is not the case, it's breaking a lot now comment: different names for different services reply: trying to reverse mapping, matching causes things to break w/o canonical name Called a rathole by the chair. 7. timezones comment; no longer any machines that don't have clocks reply; some don'tknow where they are reply; not really a requirement reply: some machines don't know GMT offset reply: capability is there in all machines, configuration of system is not our problem consensus attempt by chair; new implementations should generate uTC for received headers [?] comment: occasionally used recepit headers to check timezone originator *thinks* they are in. new consensus is back to 1123 date quick decisions: *1123 "should" should be changed to "must" for 4-digit years * go from should to must for generation of numeric timezones * 1123 "should" use return path changed to a "must" 8. [discussion about timeouts; no substantive proposal raised] q: should support size extension, require its use? [this discussion not followed on] hard to expect clients to keep looking for responses in the middle of a connection should always discourage server from closing connection unless there's a timeout q: fixing something broken, or new functionality? nothing called 9. should or a must on 8-bit MIME transport? comment: at one point, fair amount of support for should sanest way to pursue this is try to encourage widespread adoption of 8-bit transparent smtp suggestion, make it a must that we have 8-bit MIME transport to ensure this happens if a document with other than ascii, it MUST be 8-bit MIME. (No disagreement on this, but not called as a consensus item.) result: strong language, maintain should but strongly suggest MUST be 8-bit MIME. remainder of open issues punted for time reasons back to list; JK will post list back to drums-l (end of jk's part) Open 822 Issues: 1. Date header go from should to must for generatoin of num tz - yes wording for when date header should be inserted suggestion: rephrase it as 'what does the date header mean'? time of submission -- when composer hits the send button 'when you send it' needs to be behaviorally precise pete needs suggestions for specific language -- dave crocker will propose wording to encompass general concept of 'when user hits send button' q: if an MTA receives a message w/o a date, allowed to add it? No, out of scope for working group. should use lcoal tz when generating date headers? Yes. include suggestion that human readable timezone as a comment (in parens) comment: try not to put structure required on comments reply: point is to suggest this, not provide structure suggestion: provide as a hint consensus that this is a good suggestion comment: document editor can decide where it's going to go in the doc issue: concern about header ordering. suggestion: bnf needs to be fixed to be ordering-independence of headers consensus: not particularly important to specify, but if can be done cleanly in bnf, will do it suggestion to move it to bnf section make main text w/o bnf reply: want to make document as clear as possible * work item -- obsolete grammar issue: timezone must be consistent with time from MUA; must know correct GMT time reply: prescribed system behavior is bad. Keith will write up suggested wording to define this from a protocol-side, not system-behavior . Issue: ABNF, Dave C. -- allow shorter notation for extending an alternatives list across documents; for example, of doing a command list, adding commands serially across docs. [+= question] (A is derived from B or C) comment: cleaner to do a long list in pieces; when somebody has a long list in a later document, easier. example: annotate extension to IMAP -- when you are adding a new command to something. response: introduces more confusion to the reader of said document, does not simplify for reader. comment: very useful for moving obsolete grammar comment: hard to build a parser if you have to go through all this; previous example in asn.1 response: has been standard practice in BNF for a long time. response: does it hurt readers? small. little chance to misinterpret. comment: repeating the whole grammar just a waste of trees across document. But within a single, want to list them all out. comment: definition as presented by dave c. isn't complete, needs more specific notational def. -- confused with recursion. (some re-wording of proposal ensued to refine) Consensus was called for this, with defined language on list Iss: ::= pointsin favor of colon colon equals well-known symbol for is-defined-as outside of our circle being able to verify ABNF with a program would be useful, it's a lot easier with ::= to do [many disagreements] not 100% consensus, move to list issu: whitespace notation arbitrary linear whitespace legal between terminals sometimes, othertimes not. sggestion is a clean way. Agreement we need to distinguish was unanimous. third case where it's required -- example date/time nothing specific resolved gen comment: in order to ensurefuture backward compatibility, have to operate in numbers / octets (future grammars in UTF8) iss: should, in doc, specify the nature of what we are working on? consensus this should be added into document proposal: rather than defining a set of symbols, have a facility that says 'i am defining a grammar in this document, used in this other document' reply: sort of like a common standard set reply: no, more like a library -- specifically would have to say we don't include this part of ABNF suggestion: common terminals in an appendix, docs could reference suggestion: separate document, pure metalanguage with standard ref. library discussion punted to list (concern that ABNF is moving to complexity) DC will write separate document. iss: range - value...value to specify a range of values question: we have two types of values -- base octetfrom core set, plus ascii literals -- depends on how you define ranges? ans: a range is only a range between two numeric values. [some additional random blatherings at this point that resisted summary by the weary note- taker] [end] ----- Chris Newman <chrisn+@cmu.edu>, <http://www.contrib.andrew.cmu.edu/~nifty/> U.S. Citizens: Ask your representatives to support S.1587/S.1726/HR.3011 for a right to Internet privacy and encryption.