--On Monday, 14 May, 2007 16:14 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
Hi,
at the moment there are 3+1 registries for 2821bis:
1: ESMTP extensions
2: Domain literal tags, i.e. "IPv6:"
3: VIA links like "TCP", WITH protocols like "ESMTPA"
+1: trace header fields in the header field registry
There's no registry for trace clauses. FROM and BY
are required. VIA, WITH, ID, and FOR are optional.
Looking for the definition of UNNOWN-8BIT I stumbled
over RFC 1428, it defines a trace clause CONVERT.
Can we ignore this as ancient history, or ignore it
as out of scope for 2821bis, or does it need a IANA
registry ?
Frank,
Your diligence in finding these things and tracking them down
continues to amaze me. Three observations:
(1) 1428 is, indeed, ancient history.
(2) regardless of what 1428 says, the status of additional
clauses and keywords before the ";" in a Received header line is
a little dubious. Even if we now permit only a single "For"
clause, it is not clear how these things are to be parsed:
effectively, the "for" clause terminates with that semicolon,
with any tokens appearing between "for" and the semicolon being
candidates for addresses. One can use various heuristics to
get around that difficulty, or one can interpret <path> from 821
more narrowly than has traditionally been the case but, since
821 defined <opt-info> as precisely
[<via>] [<with>] [<id>] [<for>]
terminated in a semicolon, it is not clear where additional
clauses go.
Conversely, if additional clauses really are common practice and
multiple addresses in <for> are not, then we should perhaps fix
2821bis so that Opt-info is
[Via] [With] [ID] [For] [Additional-registered-clauses]
"For" is restricted to a single Mailbox (or Path), and
Additional-registered-clauses is given a strict name-value
syntax.
Since whether that change is feasible or not depends on the
implementation status of multiple mailboxes in "For", I'll leave
it to Tony as to whether an issue number should be assigned
(3) If we are going to push through as document that defines and
creates one or more additional IANA registries in this space
(see draft-hansen-4468upd-mailesc-registry), it would probably
be wise to define as many of the SMTP-related registries as
possible.
best,
john