ietf-smtp
[Top] [All Lists]

email-arch-11-05dc: version for ietf(_at_)phili, extensive changes

2008-03-09 07:05:31

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

<Prev in Thread] Current Thread [Next in Thread>
  • email-arch-11-05dc: version for ietf(_at_)phili, extensive changes, Dave Crocker <=