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

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

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

Alexey Melnikov <alexey.melnikov-usefor <at> isode.com> writes:

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

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 (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

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

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

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

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

--On 10. november 2006 13:57 +0100 Frank Ellermann 
<nobody <at> xyzzy.claranet.de> wrote:

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

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

Harald Alvestrand wrote:

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

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

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

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

In <87psbwawb7.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>Alexey Melnikov <alexey.melnikov-usefor <at> isode.com> writes:

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

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

I concur.

And RFC3977 (NNTP) doesn't support it either, and the IETF allowed that

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

Charles Lindsey <chl <at> clerew.man.ac.uk> writes:

> I concur.

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

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

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

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

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

Lisa Dusseault <lisa <at> osafoundation.org> writes:
> On Nov 10, 2006, at 10:41 AM, Frank Ellermann wrote:

>> With a MAY I'm not too surprised if my tests resulted in a 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.

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.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>

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

Lisa Dusseault wrote:

> You might raise this on ietf <at> ietf.org 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