Subject: Re: Is it necessary to go through Standards Track to Get to Historic?

From: Bruce Lilly <[email-masked]>
Date: Sun, 28 Aug 2005 17:53:27 -0400

>  Date: 2005-08-28 14:45
>  From: "C. M. Heard" <[email-masked]>

> On Sun, 28 Aug 2005, Bruce Lilly wrote:
> > The Historic category of published RFCs can be used for documents which
> > specify a protocol or technology which is known to be harmful to the
> > Internet.  However, RFC 2026 appears to have no provision for getting to
> > Historic except via the Standards Track [...]
> 
> What makes you say that?  It sure isn't what I read from RFC 2026.  It
> says this in Section 4.2.4:
> 
>    A specification that has been superseded by a more recent
>    specification or is for any other reason considered to be obsolete is
>    assigned to the "Historic" level.  (Purists have suggested that the
>    word should be "Historical"; however, at this point the use of
>    "Historic" is historical.)

That defines the sort of documents that fit into the category, but doesn't
specify how they get there.  It is analogous to 4.2.1 (Experimental) and
4.2.2 (Informational).

> Seems to me that the proviso "is for any other reason considered to be
> obsolete" could reasonably be construed to cover the initial publication
> of an obsolete specification.  It's certainly true that the most common
> way to get to Historic is to start on the standards track and then get
> retired, but I see nothing in RFC 2026 that says (or even implies) that
> this is the only way.

The only specific procedures for getting to Historic in 2026 are in sections
6.2 and 6.3 and involve getting to Historic from the Standards Track.  Note
that section 4.2.3 gives procedures for Informational and Experimental RFCs,
but that the only specific procedures for Historic are in sections 6.2 and
6.3.

Now I personally wouldn't mind a revision to 2026 where the same procedures
for Informational and Experimental were also applicable to Historic (while
retaining the mechanisms for migrating from the Standards Track to Historic).
For that matter, I'd also prefer to see the procedure modified to include
IESG review including IETF Last Call for individual submissions (2026
specifies going directly to the RFC Editor). 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 28 Aug 2005 18:13:07 -0400

>  Date: 2005-08-28 15:28
>  From: Frank Ellermann <[email-masked]>

> Bruce Lilly wrote:
> 
> > Part of the problem is UAs which suppress message header
> > fields, caused by the proliferation of "noise" fields in the
> > message header (initially SMTP "Mail-From", subsequently
> > renamed "Received", and now including a large number of
> > others).
> 
> s/Received/Return-Path/ (or is this some pre-821 history ?)

RFC 821's predecessor, RFC 788:

         The time stamp line and the return path line are formally
         defined as follows:

         <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>

         <time-stamp-line> ::= "Mail-From:" <SP> <stamp> <CRLF>

            <stamp> ::= [<ptcl>] <from-host> <this-host> <daytime>
...

> Ordinary users are most probably not often interested in the
> timespamp lines, and MUAs not showing them in their default
> configuration are fine.

Interesting typo; maybe the lines should in fact be referred to as
"timespam".

The problem with UAs suppressing header fields is that some of them
suppress important fields which communicate information from the
message originator to recipients (e.g. Reply-To).  The SMTP precedent
of modification of the message (header) content after leaving the
originator has directly led to other modifications (List- fields
and a plethora of X- fields) which in turn have led to the practice
of suppressing display of fields.  It's a tough problem for a UA
author, as there is no way to automatically determine whether some
new message header field is a new originator field (which should not
be suppressed) or some transport noise (which should be suppressed).

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 28 Aug 2005 19:01:59 -0400

>  Date: 2005-08-28 15:42
>  From: Iljitsch van Beijnum <[email-masked]>

> On 28-aug-2005, at 19:55, Bruce Lilly wrote:
> 
> > One important nit: Reply-To is an originator field (RFC 2822) and  
> > should
> > never be forged by somebody or something (e.g. list expander) other  
> > than the
> > originator.
> 
> Well, to me, the mailing list "re-originates" the message, so I don't  
> see the problem.

So you think it's OK for a list expander to modify Sender and From Fields
(the other Originator fields in 2822 sect. 3.6.2)? [some list expanders do
in fact modify Sender, causing problems]

> (Why did you set a reply-to header, then?)

To suggest where responses should be sent; that is the purpose of the field.
There is a difference between the originator setting an Originator field and
some other entity modifying an Originator field.  Unless Originator fields
are set exclusively by the originator, it is not possible for a recipient to
determine who set the field.
 
> > Kmail, Evolution, and Sylpheed each have options for sending a  
> > response to
> > the message author directly, and Pine prompts for a user decision.   
> > For
> > others, selection from a list or copy-and-paste often suffice.
> 
> The trouble is that the mail clients I'm familiar with (and that's  
> not too many, somehow learning a new one always freaks me out) give  
> the user the option to either reply to the sender (as in: address in  
> the From: header)

That would be the author(s); the sender would be indicated by the Sender
field.

> or do a group reply, where everyone else is put   
> into the CC: header. What I would really like is "reply to the list"  
> but that's not an option.

It is in fact an option in Kmail, in Evolution, and in Sylpheed (although
the implementations do not necessarily do the same thing).

> > the most effective ways to remedy the problem are to contact the  
> > supplier or
> 
> Not effective at all. My mail client is broken in several ways since  
> the last OS update several months ago, but so far, the bugs aren't  
> even acknowledged, let alone fixed. So feature requests: forget it.

Different suppliers of course provide different levels of response...
 
> > failing a suitable enhancement, to switch to a UA that does provide  
> > the desired functionality.
> 
> Is there a list of what functionality can be found where?

I wouldn't be surprised, but I don't know of any off-hand (and such things
would rapidly become out-of-date).  If you have a suitable mail environment,
the easiest thing is to experiment (a suitable environment is one where one
can easily switch user agents, e.g. where the message store is an IMAP
repository).

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 28 Aug 2005 17:33:44 -0700 (PDT)

On Sun, 28 Aug 2005, Bruce Lilly wrote:
> The only specific procedures for getting to Historic in 2026 are
> in sections 6.2 and 6.3 and involve getting to Historic from the
> Standards Track.  Note that section 4.2.3 gives procedures for
> Informational and Experimental RFCs, but that the only specific
> procedures for Historic are in sections 6.2 and 6.3.

RFC 2026 sets the rules for Internet standardization, i.e., it is
authoritative with respect to the handling of standards or BCPs.
So it's fair to conclude that the procedures in sections 6.2
and 6.3 are the only way for a standards-track document to get to
Historic.  However, RFC 2026 does not set the rules for
non-standards track documents, as it explicitly says in Section
2.1.  It is therefore incorrect to conclude from a lack of explicit
mention of a mechanism in RFC 2026 that it is impermissible to
publish an obsolete specification Historic without going through
the standards track.

There is a precedent, by the way: RFC 2341.  Note that it postdates
RFC 2026.

//cmh

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 29 Aug 2005 23:25:08 +0200

> RFC 821's predecessor, RFC 788:

Oh, yes, I should have known this, I read the "SMTP history"
archive at rfc-editor.org (once - looking for new "evidence"
for we-all-know-what-and-are-seriously-tired-of-it... :-)

>> timespamp lines
[...]
> Interesting typo; maybe the lines should in fact be referred
> to as "timespam".

I fear you've to be very brave when you start your first DKIM
review.  Until then I hope that I've found out why they _copy_
the signed header fields - it must be something obvious.

> The problem with UAs suppressing header fields is that some
> of them suppress important fields which communicate
> information from the message originator to recipients (e.g.
> Reply-To).

Normally I trust that my UA just does the right thing, Re:Mail
to Reply-To, or without Reply-To to the From.  The one thing I
simply didn't expect was that you manually set Reply-To: list.

No idea how to fix this, UAs trying to be smarter than their
user are in trouble.  In that case I was the stupid user, and
I didn't like the experience, I want to be smarter than my UA.

> It's a tough problem for a UA author, as there is no way to
> automatically determine whether some new message header field
> is a new originator field (which should not be suppressed) or
> some transport noise (which should be suppressed).

Or some wannabe-Received-SPF / Authentication-Results where an
implementor is sure that everything he does could be dangerous.

The usual game, there will be a way to configure the behaviour,
most users won't do this resulting in some default, and that
default will be very bad for some constellations.  Bye, Frank