Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/drums/drums-minutes-96jun.txt

Text File | 1996-10-07 | 15.9 KB | 476 lines

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 <[e-mail]>, <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.