Re: MTS transparency and anonymity

> On Mon February 28 2005 09:29, Keith Moore wrote:
> 
> > nobody cares about 733 anymore.  most things in use today were written 
> > with 822 in mind.
> 
> Messages tend to stick around for a long time in archives, and
> may occasionally need to be read.  RFCs are not carved in
> granite; they're amendable and have been amended (e.g. 1123
> amends 822's date-time syntax, among other things).  For that
> matter, when a 2822 successor reaches full Standard status, 822
> will be of as much interest as 733 now is -- as an historical
> document.

Nope.  There are hardly any messages around now that were written to 
conform to rfc 733.  OTOH even after 2822's successor reaches
full standard status, there will still be (US) billions of 
messages written to conform to rfc 822.  And there will still be
a few other specifications that reference rfc 822 rather than
[245]822.

Standardization status should not be confused with deployment.

>  Note that Return-Path theoretically can be an empty
> (bracketed) path, as provided for by RFC 1123. But it was not
> always so (i.e. that has changed), and a careful read of RFC 2821
> reveals that it lacks provision for an empty return path in the
> Return-Path field ABNF.  The point is that if there is sufficient
> cause for a modification, there's no absolute barrier to
> such modification. 

That's true.  But part of what determines "sufficient cause" is the
anticipated impact on the installed base.  It was much easier to
change things in the days of 1123, as the net wasn't nearly as large
or diverse then.  There wasn't so much inertia to overcome, and it
was easier to assess the impact of a proposal.

> A secondary point re. 733 is that given
> a need to make some modification to syntax, a modification
> that has some established precedent may be preferable to one
> which lacks any operational history.

It was so long ago, and the conditions are so different, that any 
precedent is of dubious value.

> > > HTTP and
> > > SIP are mentioned because they refer back to the (RFC 822)
> > > defined syntax of the From field; any change to that syntax
> > > will affect those protocols as well as the Internet Message
> > > Format.
> > 
> > no.  they refer to 822, not to some newer specification.  822 hasn't 
> > changed, and won't change.
> 
> The published text document is static, but it can be amended by
> several established mechanisms: the RFC Editor errata page, and
> through amendment by subsequent Standards Track RFCs (e.g. 1123). 

Yes, but I trust that when they amend HTTP they will do whatever
is necessary to preserve compatibity with HTTP implementations and
previous versions of the HTTP standard, not blindly update the
reference to point to the current email specification.

> > > When you propose such syntax changes, you must consider
> > > the effects on all protocols affected by the change.
> > 
> > if they are truly affected by the change, yes.  but it's not as if HTTP 
> > and SIP use email as a substrate.
> 
> They use the RFC 822 From field as defined by RFC 822 as amended
> by the mechanisms discussed above.  It would be irresponsible to
> introduce a syntax change without considering the consequences
> for HTTP and SIP.

It would be irresponsible to saddle any of HTTP, SIP, or email with
the baggage from the other protocols.

> The intent for the draft under discussion is to become a Standards
> Track RFC amending RFCs 822 and 2822.  The approach of making the
> from field optional in the Internet Message Format message header
> does not change the syntax of the From field, and does not affect
> either HTTP or SIP (because those protocols define their respective
> formats and determine which fields are permitted and/or required
> for those formats, independently of the Internet Message Format).

Yes, those things can be done.  But we do care about compatibility.
It's my opinion that the gain resulting from making the From field
optional is not worth the impact on the installed base.  
 
> > I still think that it makes more sense  
> > to use a domain literal than a domain.
> 
> We're agreed that a domain name has problems.  I'm not thrilled
> about a hypothetical domain literal which has magic properties
> unfathomable to casual users -- academic since there doesn't
> appear to be a suitable literal anyway.
> 
> > I still think it will break  
> > fewer things to have a From field with an actual address than to have 
> > no From field or From:<>.
> 
> I don't think a definitive statement is possible. Syntax changes
> would require hearing from HTTP and SIP folks. 

Not unless you're explicitly changing HTTP and SIP in addition to
email.  Of course if you are proposing to do that then you do need
to get buyin from those folks.  I don't see this as either necessary
or particularly useful.

Keith