ietf-822
[Top] [All Lists]

Re: MTS transparency and anonymity

2005-02-28 10:22:11

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