Folks,
I finally processed the backlog of suggestions for the email-arch draft.
The changed version is at:
<http://bbiw.net/recent.html#emailarch>
I'm hoping there can be some informal, face2face discussion during this week in
Philadelphia, depending on folks' interest.
The list of changes is extensive, and there are still open items, including
needing to provide the details for some citations and to add those that specify
the normative content to the draft. Also there will be more indexing references.
Here is the Changes documentation for the draft:
<section anchor="changes" title="Changes for This Version">
<t>
<list style="hanging">
<t hangText="INSTRUCTIONS TO THE RFC EDITOR: ">Remove this
sub-section prior to publication.</t>
</list>
</t>
<t>Many small editing changes, for wordsmithing improvements and to
make details more consistent. This section documents changes with
significant impact.</t>
<section title="email-arch-11-04dc">
<t>
<list style="hanging">
<t hangText="Decoupled receiving MS: ">The linkage between
a local MS and a remote one has been removed, to avoid
dealing with the messy, and apparently very rare,
interaction issues when they are linked.</t>
<t hangText="Reference to common folders: ">Tuned the
language to emphasize that the text offers a common
exemplar, not a requirement or restriction and not tied
to imap.</t>
<t hangText="Alias vs. Mailing List: "> Attempted to
clarify details about Alias and Mailing List mediators,
to make their differences objectively clear. However
it's not clear that the distinction can be held that
cleanly. </t>
<t hangText="Diagrams: "> Added emphasis to beginning and
end nodes, and distinguished primary paths from
secondary (return) paths. Before publication, non-ascii
art versions will be added for the xml document
source.</t>
<t hangText="Authentication for posting: ">Clarified
recent, increased used of submission-time
authentication</t>
<t hangText="Submission and Delivery transition: "
>Clarified figure and text to explain transfer of
responsibility into and out of MHS, with (S) and (D)
transitions in <xref target="Protocols" /></t>
<t hangText="Assigning message-id: ">Slight tweak of
language about assigning and consuming message-id.</t>
<t hangText="BCC">Removed paragraph that elaborated on BCC
usage and styles, instead just referring to RFC2822.</t>
<t hangText="Dest ADMD pre-delivery msg mod: ">Added note
that MTA in destination ADMD that changes the message is
a Gateway, not an MTA...</t>
<t hangText="Multiple Msg-ids: ">Removed reference to
messages sometimes having more than one message-id.</t>
<t hangText="Mailing list setting Reply-To: ">Added note
in Mailing List discussion about controversy of setting
Reply-To.</t>
<t hangText="Gateway examples: ">Added citations to fax,
vpim and mms gateway specs. Did not include X.400, since
it is essentially obsolete</t>
<t hangText="Auto-Responder">** pending RFC3834 ***</t>
<t hangText="Citations for normative assertions: "> ***
***</t>
<t hangText="Origin vs. Submission: ">Clarified Actor
diagram and text to map Originator actor to MSA
functionality.</t>
<t hangText="Reserved mailbox names: ">Added mention of
RFC2142</t>
<t hangText="MTA sub-roles: ">border/inbound/outbound/final
mta references.</t>
<t hangText="Mediator common info: ">Mediator section
initial text had standalone table of information. It has
been changed to refer only to information that is common
for all Mediators. Within specific Mediator discussions,
any listing of this common information is was redundant
and has been removed. </t>
<t hangText="Security Considerations: ">Meager revisions
to Security Considerations, stating that the underlying
service does not attend to them, really, and that
particular specifications cover their particular
Considerations.</t>
<t>This is intended to acknowledge the reality of Security
Considerations but defer meaningful handling of them to
concrete specifications. This architecture document
defers to specifications where possible, in order to
avoid divergent discussions.</t>
<t hangText="Internationalization: ">The document contains
no discussion of this important topic. Frankly, I have
not thought of what the document should usefully say
about the topic and am particularly worried that the
problematic and fluid nature of the topic would cause
the architecture document to conflict with the reality
of work that is underway. Offerings of candidate text
for the document, to deal with I8N are encouraged.</t>
</list>
</t>
</section>
<section title="email-arch-10">
<t>
<list style="hanging">
<t hangText="Originator->Author: "> The term "Originator"
is used by RFC 2822 more broadly than just the From:
field, which specifically defines who the author of the
content is. I believe this distinguishes two constructs,
one for the content author and one for the first agency
that handles the message, in terms of the transfer
service. So the change from "Originator" to "Author"
seems pretty straightforward. The challenge is in using
the term Originator, as defined in RFC 2822 and applying
it to the system's architecture. </t>
<t hangText="Source->Originator: "> This change is more of
a challenge. We need the "Originator" term and
construct, but the architecture is already complex
enough. Hence, adding a new construct seems like a very
poor resolution. The document has used "Source" as an
MHS term for the MSA set of functions. While one could
argue against re-labeling it as Originator, I believe
this is a reasonable choice and likely to be comfortable
for community use, since "Source" does not have an
established history. </t>
<t hangText="Bounce->Return: ">'bounce address' is not
accurate, because the address is used for more than
that, but it *is* an established term within portions of
the broader email community. I also believe the
extensive discussion on this point, last year, justifies
the change.</t>
<t>The problem with saying "Bounce" is that is not merely
linguistically impure, it is plain wrong and has already
caused serious problems. Witness SPF. Frankly, we need
to fix RFC2821, but that's a separate battle to fight
and not one for this forum.</t>
<t>Although not a verbatim use of "Reverse Path", the
related term that seems to work publicly is "Return
Address". It is already established in the
bricks-and-mortar postal world and seems to have some
acceptance within parts of the email community. (I've
done a draft white paper on authentication for the
Messaging Anti-Abuse Working Group and the membership
had some debate about this vocabulary choice and
converged on agreeing to it.)</t>
<t hangText="Is env part of message?: ">I don't remember
whether we resolved this. For a variety of reasons, I
believe the message includes its envelope, and am
encouraged to find RFC2822upd says: <list>
<t>In the context of electronic mail, messages are
viewed as having an envelope and contents. The
envelope contains whatever information is needed
to accomplish transmission and delivery. (See
[I-D.klensin-rfc2821bis] (Klensin, J., “Simple
Mail Transfer Protocol,” November 2007.) for a
discussion of the envelope.) The contents comprise
the object to be delivered to the recipient. This
specification applies only to the format and some
of the semantics of message contents.</t>
<t hangText="Deliver vs. Access: ">Cleanup the
discussion about 'delivery' out of the MHS, versus
message access by the MUA to the MS.</t>
</list></t>
<t>rfc2821bis says: <list>
<t>SMTP transports a mail object. A mail object
contains an envelope and content.</t>
</list> I think these justify having the term 'message'
as including the object. </t>
<t hangText="Examples of 'new' messages: ">Section <xref
target="msgid" /> contains a list of examples,
discussing scenarios that might or might not be viewed
as creating a "new" message, rather than retaining an
existing one. The list has been expanded.</t>
</list>
</t>
</section>
</section>
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net