email-arch-11-05dc: version for ietf@phili, extensive changes

[Dave Crocker <[e-mail]>]

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