Subject: IETF LC comment on draft-ietf-usefor-usefor-10.txt

From: Alexey Melnikov <[email-masked]>
Date: Thu, 09 Nov 2006 17:50:41 -0800

Based on LC comments, -11 will change the following sentence in section 
2.2 to use SHOULD instead of the MAY:

      News agents MAY accept header fields which do not contain the 
required space.

(MAY is too week, people would like to use MUST, but this is impractical 
due to backward compatibility.)

---

From: Russ Allbery <[email-masked]>
Date: Thu, 09 Nov 2006 18:07:40 -0800

>      News agents MAY accept header fields which do not contain the

I doubt there's any existing news software anywhere that supports this.
INN certainly doesn't.  This change basically declares all existing news
software non-compliant, and on a point where I expect most implementors to
see that change and ignore it, refusing to change their software.

I strongly disagree with this change, enough so that I would raise a Last
Call objection to it myself were it in the document at the time of Last
Call.  This is a little-used corner case of the RFC 2822 standard that
isn't even used in practice by e-mail clients on any broad basis.  A
significant amount of existing news software will outright reject such
articles, and given the slow upgrade path for news software, that will
likely continue to be the case for decades.  It's almost impossible that
such articles would ever be usefully usable in the wild, and the "feature"
is of marginal utility only (basically *only* for compatibility with an
e-mail feature no one uses).

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Nov 2006 13:57:40 +0100

Alexey Melnikov wrote:
 
> Based on LC comments

Where?  I haven't seen any public comments, only the GenArt review,
and IANA's confirmation that they looked at the "considerations".

The tracker said "waiting for writeup", and now it was switched to
"waiting for writeup - revised ID needed" by Lisa.

> MAY is too week, people would like to use MUST, but this is 
> impractical due to backward compatibility.

The magic SP issue took about one of the ten USEFOR years, touching
it now somewhere behind the scenes is execessively annoying and rude.

There are no "people" and no comments I'm aware of.  Accepting no
magic SP is clearly an OPTION in 2119-termonology, no recommendation.

The draft uses MUSTard for the magic-SP.  You can't have a SHOULD
conflicting with a MUST.  This needs a new IETF LC, it's no obscure
"experiment", where a SHOULD conflicting with a SHOULD NOT is no
big deal, or at least that's what some I* PTB decreed.

JFTR, I don't love the magic SP.  Count me in if you want to add a
note that it's ridiculous.  But no SHOULD against the WG consensus.

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 10 Nov 2006 09:30:16 -0800

I think the point is clearly made.

The chairs messed up, having forgotten part of the history.
Editor, please revert the SHOULD to a MAY; if the doc is already sent to 
the I-D queue, we'll do this via an RFC Editor note.

But - one objection to the objection:
Frank, a MUST NOT generate / SHOULD accept is no more inconsistent than a 
MUST NOT generate/MAY accept is.

                 Harald

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Nov 2006 19:41:15 +0100

> The chairs messed up, having forgotten part of the history.

That's a dark corner in the standards process, "IETF consensus"
must beat "WG consensus" if necessary.  But if the comments are
sent to "invisible" addresses (iesg@ or private mail) it's not
more obvious how the new consensus was determined.

First time that I see this as a potential problem - if I post
a comment in a "Last call" it's normally on some public list.
 
> Frank, a MUST NOT generate / SHOULD accept is no more 
> inconsistent than a MUST NOT generate/MAY accept is.

With a MAY I'm not too surprised if my tests resulted in a
series of "maybe not" (admittedly all tested servers were INNs)

With a SHOULD the magic SP MUSTard everywhere - even in appendix
C there's a REQUIRED, the very first thing listed as "important"
- would be undermined.  A new SHOULD would be also relevant for
apppendix B.

We discussed it for months, I tried all exits like 1*WSP or *WSP
instead of SP *WSP, but unfortunately they all failed miserably.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 13 Nov 2006 12:28:46 GMT

>e-mail feature no one uses).

I concur.

And RFC3977 (NNTP) doesn't support it either, and the IETF allowed that
one through without demur.

It would be more appropriate to try to persuade RFC 2822bis (there is a
draft out, but no public comments on it yet) to move that 'no SP after
colon' to its obs syntax. Nobody anywhere in the world ever generates
headers with that space missing (except when trying to 'show off' that
they cover all obscure cases).

There are a few other things that RFC2822bis should do to move nearer to
Netnews, such as making its message-ids 'octet comparable', as we have
done.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Russ Allbery <[email-masked]>
Date: Mon, 13 Nov 2006 09:25:25 -0800

> one through without demur.

Oh, good point.  I had completely forgotten about that.

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 13 Nov 2006 11:02:46 -0800

On Nov 10, 2006, at 10:41 AM, Frank Ellermann wrote:

>  But if the comments are

We don't require LC comments to be public though I agree it is nice  
to have.  The IESG is thinking about whether to change its LC  
feedback guidance to prefer the public WG lists, or the public IETF  
discussion list, over the private IESG list.  But as it stands right  
now, the latter two are specifically suggested in LC announcements,  
and no other options are forbidden.  You might raise this on  
[email-masked] if you support a change in policy or announcement text.

In general, a reasonable technical point can be raised in many ways.   
It could occur to a participant at any time instead of being  
suggested via private mail.  As far as the list is concerned, we  
might as well assume that Alexey had the idea as that it was  
suggested to him by somebody else during last call.  We shouldn't  
disallow input just because we don't quite know where it came from :)

This particular issue is not yet a matter for consensus, specifically  
it's not a matter of IETF consensus overriding a WG consensus.    
Consensus is more useful when balancing tradeoffs than when making  
corrections (and though there's no fine line between the two there is  
a gradation).

> series of "maybe not" (admittedly all tested servers were INNs)

Yes, MAY has the associated implication of "maybe not".  Thus I can't  
see how this change in itself makes any clients uncompliant.

Thanks!
Lisa

---

From: Russ Allbery <[email-masked]>
Date: Mon, 13 Nov 2006 11:44:21 -0800

>> With a MAY I'm not too surprised if my tests resulted in a series of
>> "maybe not" (admittedly all tested servers were INNs)

> see how this change in itself makes any clients uncompliant.

MAY is certainly fine (and is the current language).  Changing the MAY to
a SHOULD (in the sense of "agents SHOULD accept headers without the SP")
is a problem because, among other things NNTP requires the space:

   The headers of an article consist of one or more header lines.  Each
   header line consists of a header name, a colon, a space, the header
   content, and a CRLF, in that order.

RFC 3977, section 3.6.  We'd tried to write the NNTP specification (and in
particular the specification of the overview format and the OVER and HDR
commands) without requiring this and it added so much complexity for a
case not seen in the real world and not accepted by existing software that
we simply required it.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 13 Nov 2006 23:12:39 +0100

Lisa Dusseault wrote:

> You might raise this on [email-masked] if you support a change in
> policy or announcement text.

Yes, the next round of 2026bis is scheduled for spring 2007 directly
after the next "UTF-8 RFCs in Office formats" thread... ;-)

> As far as the list is concerned, we might as well assume that 
> Alexey had the idea

Unlikely, he wouldn't claim that his personal opinion alone is some
kind of IETF consensus no matter what the WG discussed for months -
after all he was forced to watch some rounds of these discussions.

A consistent change to "let's at least _try_ to get rid of the odd
magic SP" would require much more than one s/MAY/SHOULD/ - Bruce
posted various proposals in this direction.  I also tried it, but
it didn't fly... :-(

> We shouldn't disallow input just because we don't quite know where
> it came from :)

If it's convincing there could be a summary and a new "last call",
or better return the I-D to the WG before if it came from a WG...

Whatever took them ten years, maybe it was more difficult than some
last minute modifications of 2119-keywords.  Or maybe it was a bad
compromise after a long time, but that could be discussed in public.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 14 Nov 2006 14:05:30 GMT

>Oh, good point.  I had completely forgotten about that.

And you can add to that that RFC 1036 required it. And in the very early
days of this WG we took the view that we should not REQUIRE (or even
RECOMMEND) that News agents accept constructs that had never ever been
seen in any News Article - that was also why we ditched the obs-syntax
from RFC 2822.

And we can be quite sure that no article with that SP missing ever got out
into the wild because the software around then (as now) would have choked
on it.

Of course, an agent that handles both Mail and News will have to accept
that missing SP, which is why that "MAY" is there.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Nov 2006 18:43:24 +0000

>after all he was forced to watch some rounds of these discussions.
The issue was reraised by Dave Cridland on Apps review mailing list.

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 14 Nov 2006 22:43:01 +0100

> The issue was reraised by Dave Cridland on Apps review mailing list.

http://www1.ietf.org/mail-archive/web/apps-review/current/msg00005.html

I'd have loved to build some kind of stable converging at a magic FWS
instead of a magic SP, but months or rather years later... :-(

BTW, I didn't know that this list exists, it's no IETF list as far as
the "official" non-WG-list page is concerned:

https://datatracker.ietf.org/public/nwg_list.cgi

It also isn't listed on the "apps" area page http://www.apps.ietf.org/
or on the "apps" list page http://www.apps.ietf.org/mailing-lists.html

At least it's now clear what the remark on the apps-discuss list about
an "issue raised so far on subsetting and supersetting RFC2822" meant,
compare http://permalink.gmane.org/gmane.ietf.apps-discuss/179

Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Nov 2006 21:58:56 +0000

>they cover all obscure cases).
That would be nice. But unfortunately my Sieve parser will have to 
handle lack of the space for many years to come.

>Netnews, such as making its message-ids 'octet comparable', as we have
(chair hat off) I would encourage you to do that.

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 14 Nov 2006 19:46:38 -0800

We just started that list this year, intending to do early review of  
documents by a review team with expertise common to Apps area (XML,  
HTTP, i18n, etc).  It's currently an experiment, as we don't have a  
real process for knowing when "early review" happens or on which  
documents, but I'm working with a bunch of WG chairs to see if they  
like getting review by this list and others (like the security  
directorate review team).

Thanks for the reminder to put pointers to it at some point.

Lisa

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Nov 2006 20:36:47 +0100

Lisa Dusseault wrote:

> It's currently an experiment, as we don't have a real process
> for knowing when "early review" happens or on which documents

That "early review" rings a bell, I've read about it somewhere,
techspec or a similar list.

> Thanks for the reminder to put pointers to it at some point.

I'd know where to do it for the non-WG-list, but this would end
up in your inbox anyway - I tested the submission form for the
smtp list last year (worked, Scott got it, and it's now listed).

Frank