Subject: Non-standard language justification (was Re: #1008 USEFOR 1.5 References: Final text on "followup")

From: John Stanley <[email-masked]>
Date: Tue, 21 Jun 2005 17:26:30 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Yes. There was justification in the old article-* drafts, but it has sadly
>got lost in the rush to make USEFOR as brief (and unhelpful) as possible
>:-( .

In other words, USEFOR-04 does not document all of the differences and
contains no justification. (E.g., if "header" means something else in our
document than in RFC2822, what term do we use for the "header" as defined
in RFC2822?)

>I have seen lots of messages from abuse@... sites, but never one asking me
>to send a "full header". Lots of them asking me to send "full headers",
>though.

So, their non-conforming use of terminology in email is an excuse for us 
to propogate the use into news? I think not.

The solution isn't that hard. Let me time this ...

Oh my, a contradiction! 

   o  Compliant software MUST NOT generate (but MAY accept) headers of
      more than 998 octets. 

and:

         NOTE: There is NO restriction on the number of lines into which
         a header may be split, and hence there is NO restriction on the
         total length of a header (in particular it may, by suitable
         folding, be made to exceed the 998 octets restriction
         pertaining to a single header line).

We have a restriction on the total length of a header, and then say there
is no restriction on the total length of a header? (If one MUST NOT
generate something, one cannot then, "by suitable folding", generate said
thing.) And note that the note is patently incorrect when it refers to
"the 998 octets restriction pertaining to a single header line". The 998
octet restriction is on the "header", not the 'header line'. It is RFC2047
that contains a restriction on a "header line", and that is a measly 76
octets.

Subtracting the time spent dealing with the contradiction, a total of 
about 10 minutes converting all "header" to "header field" in the 
appropriate places. It would have been faster to apply sed and clean up 
the problem spots instead of using vi manually.

Not a very good justification for continuing to use different language. 
Was the contradiction harder to spot because we use non-standard language? 
I didn't really spot it until I tried to convert from our gobbly into 
standard gobbly and saw immediately that there was a problem. Perhaps 
there is no better reason to use standard language in a technical 
standard?

And since the point was skipped in the last response, I'll make it again.
Is there a justification for the IETF-USEFOR working group web page not to
have the latest complete draft? I know, I've asked for up to date
DISCUSSION versions to be kept on the web page so we can all discuss the
same thing and Charles nixed that because it was too hard and would take
updating the web every five minutes, but now we don't even keep an up to
date draft as sent to the IETF from three weeks ago?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 22 Jun 2005 22:13:25 +0200

> date draft as sent to the IETF from three weeks ago?

The chairs will attempt to get this fixed.
Version numbers are cheap (outside of the IETF pre-meeting blackouts), so 
we might as well just ship official versions (my opinion). I hope we have 
enough issues settled to make it worthwhile to ask our editor to emit 
usefor-05 before the Paris blackout.

                    Harlad

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 22 Jun 2005 22:13:25 +0200

Harlad