DRUMS Meeting Minutes
Intro
WG Chair Chris Newman outlined the agenda for the two DRUMS mtgs this week.
In addition to consideration of current issues for ABNF, 822bis and 821bis,
we would spend ~10 minutes on a new proposal from Jacob Palme to consider a
mail header registry. On Tuesday we took up ABNF, and outlined issues for
821bis. On Friday we covered 822bis, 821bis and Jacob's proposal.
ABNF
In introducing Dave Crocker, the ABNF editor, Chris noted that perhaps only
1 more draft of ABNF would be required before advancing. As Dave got up,
he jokingly assured the working group there would indeed, be only one more
revision. The working group fervently hopes he is right.
Dave summarized the consensus the list construct be removed. He noted
there were some minor editorial changes, and there is a single range
construct.
The only remaining issue to be settled is the list of "core set"
definitions in Appendix A. He proposed removing <PCHAR-NRB>, <PCHAR-NDQ>,
and <LWSP>. During the meeting, we agreed to replace the symbol "HT" with
"HTAB", as more descriptive of the character's typical rendition. While we
considered adding UTF8 to the core set. The lack of consensus regarding
UTF8 outside of drums led us to removing it from the literal list. We
agreed to add the rule OCTET ( = %x00-FF), and agreed to remove %x00 from
CHAR. [Did we remove CHAR altogether? My notes indicate this, but I don't
clearly recall. -- jwn2]. After some debate we chose to define VCHAR (=
%x21-7E) replacing PCHAR.
The last discussion regarding ABNF during the meeting considered the use of
"<" and ">" in <prose-val>s. Some interpreted the rules to yield multiple,
ambiguous definitions of the use of these characters. This would make
machine parsing of ABNF impossible. [jwn2's note: I don't see this
interpretation in -03. I'm not sure this paragraph has any relation to
what really occurred...]
Before adjourning for the day, we briefly discussed 821bis issues. The
editor and WG agreed to defer thorough discussion until Friday.
822bis
The 822bis editor, Pete Resnick, led the discussion on 822bis open issues.
There are a number of issues to consider that hadn't been resolved on the
mailing list. The goal is to get all substantive issues into the next
draft, and allow one final draft for small editorial changes.
addr-spec needs better name, addr-spec is probably the one used
Pete is searching for a better name for addr-spec than "addr-spec".
Without some inspiration from someone in the working group, he'll choose
addr-spec, and wish he had something better.
msgid syntax is message-id: <lhs @ rhs>
While there is no dispute that message-id conforms to lhs@rhs, handling the
requirement that message-id be globally unique has proved difficult. The
draft should include some guidance for implementors on how to insure
uniqueness.
The description should roughly follow this plan:
If the rhs is unique, then any lhs is ok. Otherwise, implementors must use
some convenient method to insure the lhs is unique. They must take care
that message-id doesn't reveal more information about the originating
station than is revealed by other headers. The rhs should conform to dns
name generation rules, although it is not required the rhs be a name valid
in some domain. In addition, the editor was encouraged to identify
potential pitfalls in name choices.
empty mailbox list item
The editor sought guidance on handling empty mailbox list items. In
particular, should their use be discouraged? It was observed there are
times when an empty list item is convenient, so it was agreed they would
remain in the accept grammar, ie, constructs which are obsolete, but should
not be allowed in the generate grammar, the grammar used for new
implementations.
3.6 to, cc generate max 1 list
It was observed that the requirement to generate a single instance of
addressee fields (to, cc, bcc) invalidates the practice of old versions of
sendmail. However, all understood that 822's statement that implications
of this form as "undefined" is inadequate. The consensus was that
mandating only one instance each of these fields in the generate grammar,
but allowing multiple instances in the accept grammar was the best course.
cfws in group
The editor had noted there was no consensus whether cfws in groups should
be allowed for both accept and generate grammars. Those in attendance had
no objection to it appearing in both places.
phrase -> formalname in mailbox (group-name in group)
Pete wants to use a more descriptive term for "phrase", one that is more
reflective of phrase's use. "Display name" was offered as suggestive of
the purpose a MUA could make of the phrase. There was no objection to
"display name", so it will be adopted.
in accept grammar 2/3 digit year "MUST" or "SHOULD"?
The discussion was brief, although somewhat testy. Mostly it was "let's
get past this one". The group converged on "SHOULD". (3-digit years --
bleah!)
CFWS after field name in obsolete syntax (accept grammar)
The -02 draft allows *CFWS between the field name and the ":" marking the
end of the field name token. The WG attendees preferred *WS or *FWS, and
disallowing comments.
X- Headers
During the meeting it was observed that no X-* header has any standard
semantic value. Nevertheless, they are an important mechanism to explore
new possible semantics. So their use and interpretation should be
discouraged. [jwn2's note: Still this sounds suspiciously like where we
left multiple recipient list fields, and see where that led.]
Should a header registry be included in this document?
Jacob's proposal for a header registry was noted, and the WG agreed that,
at most, 822bis should refer to this registry.
Received / Return-Path
One of the knottier remaining problems for 822bis is semantics for Received
and Return-Path headers. Clearly the information contained in the headers
is generated by the MTA. The audience for 822bis is conceived of being MUA
authors, so discussion of these headers in 822bis seems misplaced.
However, 822bis must define the syntax, including a mechanism for extending
the header. This was proposed by Chris Newman and Robert Elz. Dave
Crocker wants to be sure that 822bis defines the syntactic entities
commonly found in the header. Strong consensus among the attendees was
lacking. Finally the editors of 821bis and 822bis agreed to work out
between them what is discussed where, and propose their resolution to the
list.
3.6.6 "forwarding" and Resent-*
The discussion of forwarding in 3.6.6 was thought to lack sufficient
clarity and objectivity. The editor was encouraged to rephrase the
discussion and add examples.
Reply-to
The last substantive issue was semantics of the Reply-to header. Two
different semantics were described: the "From:" field isn't changeable, you
should use "Reply-to:" value instead; ignore the rest of the recipient
list, reply here, instead. [My notes are unclear on the resolution of this
discussion -- jwn2]. The recommendation of the group is that description
of "Reply-To:" make clear its use in the context of a mailing list.
Administrivia
Remaining issues were administrative ones, regarding 822bis. The editor
promises examples in the next draft. He encouraged and requested careful
examination of the examples. It was suggested he borrow heavily from the
examples provided in 822. It is anticipated this all substantive issues
will be incorporated into the next draft, with one more to handle minor
textual revisions.
With that we returned to 821bis.
821bis
6.3 MTA editing
The current draft prohibits smtp relays from editing the message content
beyond the addition of trace fields, while allowing an originating smtp
node to edit the message to complete required fields omitted by a mua.
There has been some discussion that relays be allowed more latitude to edit
messages, as that occurs in current practice. Those in attendance at the
meeting, however, prefer this not be allowed. The consensus of the meeting
was to leave the language as it stands.
Size Limits (line length limits)
This discussion (which began in the first meeting) considered whether there
was any better way to express the consequences of dealing with arbitrarily
long lines of text in the mail data than was offered by the editor in the
draft. The conclusion was, "no". So the text was left as it stands.
452 vs 552 response codes
Another issue provoking much discussion on the mailing list was the
intended use of these response codes. The WG conclusion is that 552 is in
response to a specific "rcpt to" command -- the receiver could not handle
this particular command. It is not invalidating all recipients gathered up
to that point. The editor will offer new language on the difference
between 400 and 500 response codes to clarify this difference.
multiple MXs at the same level
RFC974 permitted this, but 821bis does not. After discussion at the
meeting, the editor agreed to reexamine his wording.
IPv6 address format
Those in attendance at the meeting agreed to replace the space separating
the identifier from the value with a colon. Currently 821bis refers to a
Proposed Standard for the address format that must be recycled. So the
editor, chair and possibly AD(s) will attempt to prevail on the IPv6
working groups to provide DRUMS with an updated description.
"LF.LF" disallowed
Eric Allman (through a proxy) registered his dislike for this condition.
However, the WG consensus is that future versions of sendmail will have to
live with this in order to be compliant.
NULs in DATA
It was noted that 821bis doesn't prohibit NULs in DATA. However, 822bis'
generate grammar forbids them. Some thought this was inconsistent.
However, it was pointed out that 821bis may be used to transmit objects
other than 822bis messages for which NULs may be acceptable. So
eliminating NULs from 821bis is a Bad Idea. And so the language will be
unchanged.
3.5.2 VRFY
The description of VRFY in 821bis still doesn't resolve the ambiguities
between RFCs 821 & 1123. It was also claimed that descriptions of ehlo
provide conflicting descriptions of VRFY. [But I don't seem them -- jwn2].
The language on the addr-spec response to VRFY by the server needs to be
clarified.
4.4 Received "for" phrase
Concern was expressed for the security implications of multiple recipients
listed in the For phrase of a Received header. It was pointed out that
822/822bis BCC'd addressees may appear in this field, compromising their
identity. In different cultures, violating the secrecy of Bcc can have
severe consequences. The phrase "SHOULD NOT generate a multiple recipient
'for' phrase when there are multiple RCPT TOs" was suggested. The editor
agreed to take this under advisement and add this to the security
considerations.
That completed discussion of 821bis.
Mail Header Registry
Jacob Palme gave a summary of a draft protocol to register message headers.
The principle purpose of the registry is to avoid semantic ambiguities in
headers. Jacob defined homonyms as a header with multiple interpretation,
and synonyms as different headers with the same or similar interpretations.
A goal of establishing the registry is to avoid both homonyms and synonyms
in message headers. It will be possible for anyone to register a header.
Registrations are subject to peer review before they are accepted. The
draft describes the review method.
The chair solicited opinions from the WG attendees whether such a registry
would prove beneficial. The rough consensus is it would be worthwhile.
The chairman accepted the document as within the WG's scope. He will
modify the charter accordingly and submit it to the Area Directors.
Chairman's Summary
ABNF should be ready for a WG last call by the end of August. It is
desirable for a 3rd revision of 822bis be presented to the WG by the end of
August as well. He expects that comments elicited by the 3rd draft may
require a 4th draft, but the 4th should result in a WG last call. A new
revision of 821bis should be made ready in early September, and be the
basis of a WG last call. Finally, a revision of the registry draft should
be prepared by the end of August for consideration by the WG. It is
expected that comments from the WG last calls will demonstrate the need for
a meeting at the Dec IETF meeting. There being no further business, the
chairman adjourned the meeting.
john noerenberg
[email protected]
pager:
[email protected]
--------------------------------------------------------------------
"We need not to be left alone. We need to be really
bothered once in a while."
-- Ray Bradbury, Farhenheit 451, 1953
--------------------------------------------------------------------
