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. 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.  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.

> > 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). 

> > 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.

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).

> Everything is 
> broken in some way or another.

That's been my premise from the start.

> 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.  I've yet to hear
of a single specific thing that breaks badly in the absence of
a From field in a message -- aside from systems that lack any
provision for anonymity in the first place.