Subject: [Fwd: More information requested on publication status of draft-crocker-email-arch]

From: Alexey Melnikov <[email-masked]>
Date: Tue, 26 May 2009 22:42:17 +0100

[I am trying to avoid crossposting to 5 different mailing lists.]

Subject: More information requested on publication status of draft-crocker-email-arch
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Date: Tue, 26 May 2009 22:40:16 +0100

There have been two Last Call notices sent to the IETF for:

    'Internet Mail Architecture' <draft-crocker-email-arch> as a 
Proposed Standard

The IESG has received a concern about the intended publication status of 
this document and wishes to confirm the community's preferences.
As the shepherding AD I would like to request more feedback on this 
topic. Please send your answers by the end of June 3rd.
You can either reply to this message, send your response directly to 
[email-masked], or send it directly to me and Tony Hansen <[email-masked]>.

Please indicate your preference for publishing the document as:

    1. Proposed Standard, as queried in the two Last Call notices

    2. Informational

    3. Some other label

    4. I have another opinion (please describe)

Also please indicate your reason(s) for this choice.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 26 May 2009 17:08:39 -0500

>    1. Proposed Standard, as queried in the two Last Call notices

I believe it should be Proposed Standard.

>Also please indicate your reason(s) for this choice.

Restating something I sent to the IESG separately earlier:

This is an architecture document. We don't do these much anymore in 
the IETF, and this one is particularly strange because it is 
describing an architecture for a deployed service. However, I don't 
think that means we should shy away from it. We in the email 
community have needed this document for a *very* long time. We end up 
re-discussing architectural issues in each new WG just to get our 
terms straight and constrain solution spaces (cf. LEMONADE, MARID, 
DKIM). And we need to have a document to point to so that newcomers 
can couch their proposals in terms we understand without having to 
re-argue the model every time. But in order for it to work in these 
roles, and for it to have the ability to evolve over time, it really 
needs to be a standards track document.

Yes, there will inevitably be differences between the overall 
architecture of the system and the protocols that instantiate it. 
There are simply pragmatics which make such compromise required, and 
it is in fact a healthy tension. And yes, that fact means that some 
people will do stupid things, like claiming that where the 
architecture and protocols diverge, the architecture must win. There 
will always be such folks who don't understand that sometimes 
pragmatics prevail over architectural purity. But I think to not call 
this document what it is (i.e., an evolving community consensus on 
the email architecture) in fear of how it might be used is frankly a 
bit nuts. Let's address the problems as they arise rather than 
further diminishing the meaning of our document series.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 26 May 2009 20:07:16 -0700

Alexey Melnikov wrote:
>    'Internet Mail Architecture' <draft-crocker-email-arch> as a Proposed 
> Standard
> 

Folks,

As the document's author, my preference for its status is obvious.  But I 
thought it worth commenting on the reason I believe a document of this type -- 
and this particular document -- warrants standardization.

Any protocol specification that we do standardize is a component of an 
integrated service.  Standardizing a component, without standardizing the 
context into which is it being used, is a bit like writing a precise contract 
for a supply of screws or a heating element or bits of sheet metal, but not 
specifying their integration into a toaster, or some other particular 
(integrated) product.

The screws or heating elements might be used for a variety of other products. 
There's nothing wrong with that.  Those other uses do not constitute a 
"violation" of the toaster specification.  They're just different.

So it should be for an integrated service like Internet Mail.  We did not feel 
compelled to do the specification long ago because back then the service began 
in a kind of cottage industry within a small community. The systems 
specification was informally shared.  The community, now, is much larger and 
shares none of that original history.  This constantly causes confusion in 
discussions about the integrated service.  So, that community needs to see a 
specification for this particular service we call Internet Mail.

They need to see it as a standard for the same reason they need to see the 
components as standards.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Doug Otis <[email-masked]>
Date: Wed, 27 May 2009 11:40:55 -0700

On May 26, 2009, at 8:07 PM, Dave CROCKER wrote:
>> The IESG has received a concern about the intended publication  
>> status of this document and wishes to confirm the community's  
>> preferences.
>
> Folks,
>
> As the document's author, my preference for its status is obvious.   
> But I thought it worth commenting on the reason I believe a document  
> of this type -- and this particular document -- warrants  
> standardization.
>
> Any protocol specification that we do standardize is a component of  
> an integrated service.  Standardizing a component, without  
> standardizing the context into which is it being used, is a bit like  
> writing a precise contract for a supply of screws or a heating  
> element or bits of sheet metal, but not specifying their integration  
> into a toaster, or some other particular (integrated) product.
>
> The screws or heating elements might be used for a variety of other  
> products. There's nothing wrong with that.  Those other uses do not  
> constitute a "violation" of the toaster specification.  They're just  
> different.
>
> So it should be for an integrated service like Internet Mail.  We  
> did not feel compelled to do the specification long ago because back  
> then the service began in a kind of cottage industry within a small  
> community. The systems specification was informally shared.  The  
> community, now, is much larger and shares none of that original  
> history.  This constantly causes confusion in discussions about the  
> integrated service.  So, that community needs to see a specification  
> for this particular service we call Internet Mail.

While this document has value, and I would like to applaud your  
effort, it seems counter productive to impose architectural concepts  
as the definition of a standard.  While the introduction that Pete  
suggested helps, it may become difficult to know which documents are  
authoritative.  Your description of this document does not help.   The  
status of standard should be limited to documents that describe  
specific interactions, where these protocols may conflict with  
previous architectural concepts that carry the status of  
informational.  In doing so, there would be less danger of confusion.

> They need to see it as a standard for the same reason they need to  
> see the components as standards.

Email was not defined in this fashion, nor are the many aspects of  
interaction related to email assured to remain compliant with any  
fixed architectural concept.  The components of a standard define the  
interaction.  There is no overarching requirement to remain complaint  
with a general architecture, nor should there be at this time.   Email  
is currently suffering from what might be described as the tragedy of  
the commons, and an aversion of some providers to identify  
themselves.  It seems inevitable that subtle changes to email  
architecture will be needed.   Having such efforts considered out-of- 
standards compliance may inhibit otherwise necessary changes.  If  
email was not suffering from such levels of abuse, the situation could  
be different as a general change would not be desired.  As such, it  
seems a less disruptive and less confusing to adopt this as a highly  
valuable informational document.

-Doug

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 May 2009 21:56:19 +0200

On May 27, 2009, at 20:40, Doug Otis wrote:

> [...no way to...] remain compliant with any fixed architectural  
> concept

We might need a new document class, "Best Current Architecture" (kind  
of the inverse of BCP).

Gruesse, Carsten

---

From: Thomas Narten <[email-masked]>
Date: Thu, 28 May 2009 08:28:12 -0400

>     1. Proposed Standard, as queried in the two Last Call notices

Standards Track is an odd category for an architectural document. If
the argument is "it needs to be on standards track in order to have
more weight", I understand that the argument, but that doesn't make it
right. (As an exercise, look at the  RFC index, and search for
documents with "architecture" in the title. Very few are on the
standards track.)

Traditionally, standalone architecture documents have been
informational. One reason is that it generally makes no sense for an
architectural document to advance up the standards track. In the light
of draft-dusseault-impl-reports-02.txt, exactly what features of the
architecture would one test in an implementation report?  If the
answer is "such a test makes no sense", it seems rather odd to have
the document on the standards track in the first place.

Thomas

---

From: SM <[email-masked]>
Date: Fri, 29 May 2009 11:36:13 -0700

At 14:42 26-05-2009, Alexey Melnikov wrote:
>status of this document and wishes to confirm the community's preferences.
>topic. Please send

It would disingenuous of me not to acknowledge and commend the effort 
by Dave in writing this draft about Internet Mail.

>Also please indicate your reason(s) for this choice.

There is an obsoleted "Request for Comments" (it's not a RFC) from 
the Network Working Group which was distributed to six people.  One 
of the six people is most likely subscribed to one of the mailing 
lists this message is addressed to.  I'll quote a few lines from the document:

   "Philosophical positions without examples or other specifics,
    specific suggestions or implementation techniques without
    introductory or background explication, and explicit questions
    without any attempted answers are all acceptable."

The document also stated that one of the reasons for the standards 
(or lack of them) is that:

   "There is a tendency to view a written statement as ipso facto
    authoritative, and we hope to promote the exchange and discussion of
    considerably less than authoritative ideas."

The discussions between various IETF participants about this draft 
highlight the philosophical differences about Internet Mail.  In 
spite of these philosophical differences, there has been "standards", 
Informational and Experimental documents about email.  Some of the 
standards have matured into Internet Standards.  The name may sound 
grand.  If you think about it, we rely on its acceptance by the 
Internet community.  Internet Mail share a similar characteristic in 
the sense that the message delivery relies on the acceptance by part 
of the Internet community, the broader the better.

Some people view published documents as authoritative.  If you say or 
do something wrong, someone might tell you "read the RFC" or "the RFC 
says so".  I prefer the former when the RFC contains a good 
explanation.  Sometimes an RFC doesn't explain why things are done in 
a particular way.  Over the years, most, if not all, of the authors I 
have come across have graciously explained the why when I sent in a question.

I don't adhere to the practice of using a "standard" as a bat as it 
is not a good way to promote ideas or to encourage adoption of the 
"standard".  It may be frustrating for those that have been around 
for a long time to hear the same questions and having to repeat the 
same answers over and over or to field off technically naive 
proposals.  I hope that the author of RFC 875 won't mind the minor 
change I made in quoting the following:

      Often, it's the Oral Tradition that matters; some RFCs, in their
      attempts to seem scholarly, offer the wrong levels of abstraction
      or, because of the backgrounds of their authors, are so
      ill-written as to fail to communicate well.  Sometimes, however,
      that which is truly relevant turns out to be unfindable by a
      conventional literature searcher because it isn't "in" the field
      of search.

Regards,
-sm