Subject: Re: Issues outstanding

From: Alexey Melnikov <[email-masked]>
Date: Thu, 07 Apr 2005 12:10:54 +0100

Ken has just published a new revision of USEFOR (03). Some comments on 
the changes and how they relate to the list of issues below:

Charles Lindsey wrote:

>Some while back I posted a list of issues (and our Chair added some more).
>We have now reached the point where we cannot continue working on our
>drafts until these are resolved.
>
>So here is the list again, with my comments on where we are at on each
>one. SO PLEASE CAN WE HAVE INPUT ON THESE, especially on the ones which
>still appear to be OPEN?
>  
>
>>We are coming to the point where there is little more that can be done on
>>the documents we are supposed to be producing without deciding how various
>>outstanding issues are to be resolved.
>>    
>>
>
>1. Complaints-To
>
>  
>
>>I published a list of 4 options (and invited other options) in
>>http://www.imc.org/ietf-usefor/mail-archive/msg00151.html. Only three
>>people have expressed any preference amongst them. I think #4 is dead, and
>>#2 is the one most people could live with (but on such a small sample,
>>that is hardly meaningful).
>>    
>>
>>#2 was to do it in Injection-Info rather than in a Complaints-To header,
>>and to provide only a mail-complaints-to parameter (which would leave open
>>the option to provide a separate url-complaints parameter as a future
>>extension).    
>>
>
>I think the conclusion we reached on this was to have a
>'mail-complaints-to' parameter in the Injection-Info header with an
><address-list> for its parameter. And we decided not to have any provision
>for URLs at this time, though a url-complaints-to parameter could be added
>as a future extension if there was a demand for it.
>
>If that is agreed, then this issue is CLOSED,
>
This change is done as well as description of different parameters.

>except for deciding whether
>multiple <address>s meant you were supposed to reply to ALL of them, or to
>ANY ONE of them. Input on this is still needed.
>
This minor issue is still open.

My personal opinion is that if there are multiple email addresses they 
all should be treated as equal and mailing to ANY of them should suffice.

>
>2. Path header delimiters
>  
>
This is still open.
[...]

>  
>
>3. Mail-Copies-To and Posted-And Mailed
>
>  
>
>>Available options appear to be:
>>
>>1.  Include them as in draft-13
>>2a. Defer them to a future document (standards-track)
>>2b. Defer them to a future document (experimental)
>>3.  Drop them entirely
>>    
>>
>>Earlier discussions were inconclusive. I gather our Chair prefers #2 (a or
>>b), but he has made no definitive pronouncement.
>>    
>>
>
>I think all that the discussion established was that it was as much effort to
>remove them (from USEPRO) as to add them (to USEFOR). It is still not clear
>(to me) what the objection to keeping them is, and I see no merit at all in
>#2b (since these headers are in moderately common use, and the "experiment"
>has, in effect, been done).
>
>So this issue is still OPEN.
>
This issue is closed now: the headers will not appear in the USEFOR 
document. The choice between 2a/2b/3 is up to the WG.

>
>
>4.  Terminology for followups.
>
>  
>
>>1. A followup is a response, and MUST have a References header. A part of
>>  a multi-part FAQ (or anything similar) is not a followup, but it MAY
>>  nevertheless have a References header.
>>
>>2. A followup is a response, or a part of a multi-part FAQ (or anything
>>  similar). A followup MUST have a References header, and anything else
>>  MUST NOT have one.
>>
>>It has been established that there is no technical difference between
>>these formulations. It is just a matter of wording, so a simple majority
>>for one of the other should settle the matter.
>>
>>There are alternative definitions in USEPRO, but no corresponding wordings
>>for the References header in USEFOR yet, so maybe we should wait until
>>there are.
>>    
>>
>
>This one is still OPEN. There are two alternative texts in USEPRO, but the
>matching alternative texts for USEFOR are not in place yet (I hope Ken is
>working on them). So I am happy to let this one be for now. There is no
>technical issue involved - just a question of how to define things.
>
I don't believe that anything in the USEFOR should be changed, so this 
issue concerns the USEPRO document at best.

>
>
>5. Review Injection-Info syntax (this might be related to Complaints-To)
>
>I invited proposals from anyone who wanted to pursue this. I received none, so
>I think this one is CLOSED.
>
The updated USEFOR draft now includes description of different parameters.
If people want an alternative syntax, please speak up now!

>
>We all agree that RFC 2231 is ugly, but most of it is quite unnecessary in
>Netnews. I would be happy for this to be pointed out in USEFOR with suitably
>discouraging wording.
>
>6. Remove filename parameter from the Archive header.
>
>I think we concluded that the filename-parameter (and perhaps other
>parameters) might well be useful in the future, but there was no need to
>define them now. Therefore, we should just keep provision for MIME-style
>parameters in this header (so software would be required to ignore such
>parameters for now), but leave the definition of any actual parameters for
>future extensions.
>
In the latest USEFOR draft the filename parameter was replaced by a 
generic parameters.

>
>
>7. FWS issue in headers.
>
>Frank was very keen to introduce *FWS rather than *CFWS or *FWS in various
>headers to cope with the rule that folding should not result in empty lines,
>or even in lines with empty content. It was established, however, that the
>present verbiage covering this issue would still be needed because it was not
>possible to solve all such cases syntactically. I argued that there was no
>point in changing only those cases where it would work, thereby introducing
>differences from RFC 2822. Note that this issue involves no technical change -
>just the method of description.
>
>Frank received no other support, and I propose to do nothing. If Ken wants to
>make these changes to USEFOR, then so be it. I regard this one as CLOSED.
>
I tend to agree.

>
>
>8. Define a Message-ID compatible with NNTP, get rid of NO-WS-CTL.
>
>We agreed to get rid of NO-WS-CTL (it would have been incompatible with
>the new NNTP draft), but our Chair rules that further departures from RFC
>2822 were not to be allowed. So I think this is CLOSED.
>
>
>  
>

NO-WS-CTL have been removed. Can people check that the new syntax is Ok?
I suspect that some minor issues raised by Frank are yet to be addressed.

> So could people who disagree with the ones I have marked CLOSED please
>speak up, and otherwise will our Chair please confirm that they are
>CLOSED.
>
>And please may we have discussion of the ones still OPEN, especially the
>Path header one.
>
>  
>
Alexey

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Apr 2005 08:10:53 +0200

Alexey Melnikov wrote:

>> Frank received no other support, and I propose to do
>> nothing. If Ken wants to make these changes to USEFOR, then
>> so be it. I regard this one as CLOSED.

> I tend to agree.

One last attempt, the subject of this article is a German fun
word:  Donaudampfschifffahrtskapitänsmütze.  The 3 "fff" are a
case of de-DE-1996, I use RfC 2231 and one B64 UTF-8 word.

It is too long for RfC2047, therefore it's folded with a FWS.
This violates a MUST in Usefor-03, but it's a valid RfC 2822
mail header field.

So now what, shoot my UA (in theory, in practice I edited the
subject manually) ?  Let some "injection agent" fix it ?  Or
reject it ?  What about mail2news gateways ?  

                        Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 8 Apr 2005 20:11:05 GMT

>This violates a MUST in Usefor-03, but it's a valid RfC 2822

It is indeed, but since it is in breach of RFC 2047, a conforming reading
agent SHOULD render it exactly as received ('=?...?=' and all). However,
some kind agents _might_ try to decode it for you.

The proper way to create that header is as:

Subject: =?UTF-8*de-DE-?B?RG9uYXVkYW1wZnNjaGlmZmZh?=
         =?UTF-8*de-DE-?B?aHJ0c2thcGl0w6Ruc23DvHR6ZQ==?=

That works because, if you have two encoded words with nothing but FWS
between them, then the decoder is required to ignore the FWS. And you have
to be careful where you make the split, because each encoded-word must
encode an integral number of octets (so after a multiple of 4 for base64,
and watch out for '=xy' in Q-P). And on top of that you must not split any
multi-octet character between the encoded words (which could be tricky in
UTF-8, where the number of octets per character is variable).

But any decent MUA ought to be able to do it. I tried it in Opera, and it
produced:

Subject: =?utf-8?Q?Donaudampfschifffahrtskapit?= =?utf-8?Q?=C3=A4nsm=C3=BCtze?=

OK, it used Q-P rather than Base 64, but it was quite happy to display the
original word without any spaces in the middle when read back.

BTW, your message achieved a Spammassassin score of 3 :-( .

-- 
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: "Charles Lindsey" <[email-masked]>
Date: Fri, 8 Apr 2005 21:32:34 GMT

>the changes and how they relate to the list of issues below:

There is still an awful lot of stuff that is meant to be covered in
USEFOR, but still isn't. But that is for another thread.

>This change is done as well as description of different parameters.

Yes, but not quite as agreed, because the token he has given for the
parameter is 'complaints-to', rather than 'mail-complaints-to' as we
agreed. That will not satisfy the people who wanted to leave room for a
'url-complaints-to' parameter as a future extension.

>This minor issue is still open.

As currently written, the <value> of that parameter is an
<address-list>, which by default means "send to them all" (cf. the
Reply-To header).

>all should be treated as equal and mailing to ANY of them should suffice.

That could be achieved by adding some wording to say so. I am easy either
way, so we need to hear more opinions.

>>2. Path header delimiters

Shame! I though we had more-or less agreed on that one. OK, I shall start
another thread to discuss that.

>document. The choice between 2a/2b/3 is up to the WG.

Actually, I have now come to the conclusion that this problem is far worse
with mailing lists than it is on Usenet, so it might be better to fix it
there, maybe based on Mail-Followups-To with some extra features to
incorporate News. Indeed, there was some discussion on the ietf-822 list
about Mail-Followups-To as a possible solution, with many in favour but
two diehards implacably opposed (for completely opposite reasons). Ours is
not the only list that suffers from long discussions with no decision at
the end :-( .

(Oddly, I noticed that John Stanley was in favour of Posted-And-Mailed -
he is quite right, but if Mail- Copies-To has to wait, then
Posted-And-Mailed must wait too.)

I shall now remove all mention of both these headers from USEPRO.

>issue concerns the USEPRO document at best.

Could you please explain your reasoning here?

ISTM that any header described in USEFOR needs the following information,
as appropriate:

1. A brief statement of what the header is supposed to achieve.
2. Its syntax.
3. Its semantics (i.e. what information is conveyed by its various
syntactic parts).
4. Any restrictions or requirements on when it is to be used (e.g. it is
"mandatory", or it MUST/SHOULD [NOT] be present if such and such other
circumstances pertain).

Following #4, there has always been a statement like the following
associated with this header:

   A followup MUST have a References-header, and an article that is not
   a followup MUST NOT have a References-header.

It is particularly important to say that here, because it is a change from
RFC 2822, where the word used is only SHOULD.

Now the precise wording of that varies according to exactly how the term
"followup" is defined (and that is what this issue is all about). But both
sides to this argument are agreed that that "MUST" needs to be said, and
this is (AFAICS) the only place where it could be said.

Yes, USEPRO describes in detail how to construct this header in the
particular case of responses/replies to earlier articles, but there are
other applications for it also, for example multipart FAQs and
message/partial (and again it is common ground that these are legitimate
applications).

>If people want an alternative syntax, please speak up now!

Well nobody has spoken on this for a long time. I think the important
thing is that Russ declared that he could live with this syntax, and I
think his opinion is important. But I think we also need some deprecatory
remarks to discourage the wilder (and unnecessary) extremes of RFC 2231
(and please can we use that lovely word "gibbous" in them :-) ).

It is nice to see all the other Injection-Info parameters fully described.
I have a few niggles about the precise details, and there are issues
regarding the way they have been introduced syntactically, but that too is
for another thread.

>In the latest USEFOR draft the filename parameter was replaced by a 

Fine!

>I suspect that some minor issues raised by Frank are yet to be addressed.

Yes, there is a placeholder "[[Adjacent dots should not be allowed]]" for
Frank's problem, but we still need some syntax to plug in there.

We also need some wording drawing attention to this extra departure from
RFC 2822, and referring to [NNTP] which necessitated it.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 09 Apr 2005 06:14:38 +0200

Charles Lindsey wrote:

>> it's a valid RfC 2822 mail header field.
> It is indeed, but since it is in breach of RFC 2047

It shouldn't, I've sent it in two lines, 2nd line 76 characters:
Subject:
 =?UTF-8*de-DE-1996?B?RG9uYXVkYW1wZnNjaGlmZmZhaHJ0c2thcGl0w6Ruc23DvHR6ZQ==?=
....5...10....5...20....5...30....5...40....5...50....5...60....5...70....5.

http://article.gmane.org/gmane.ietf.usenet.format:28154:raw
says that "something" between me and GmaNe "fixed" this, but
generally my UA is innocent if it comes to attempts of being
smart.

>          =?UTF-8*de-DE-?B?aHJ0c2thcGl0w6Ruc23DvHR6ZQ==?=

Sure, you and me know this, but I'm talking about existing MUAs,
mail2news gateways, injection agents, servers, and newsreaders.

> BTW, your message achieved a Spammassassin score of 3 :-( .

1st UTF-8, 2nd B64, what was the 3rd ?  Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 09 Apr 2005 06:55:19 +0200

I've just tested it with two news servers, and both rejected a
"Subject:" SP CRLF SP "stuff" CRLF

So "fixing" the FWS issue by removing the separate MUST about
non-empty header body lines Usefor-03 would be a very bad idea.

Maybe I should a post an I-D "Subject: Re: considered effective
at least" mentioning this case.

---

From: "Charles Lindsey" <[email-masked]>
Date: Sat, 9 Apr 2005 19:33:52 GMT

> =?UTF-8*de-DE-1996?B?RG9uYXVkYW1wZnNjaGlmZmZhaHJ0c2thcGl0w6Ruc23DvHR6ZQ==?=

Ah! It was all on one line when I received it, so I didn't understand what
your problem was.

>mail2news gateways, injection agents, servers, and newsreaders.

Well if the sending agent cannot figure how to do it that way, then it
will just have to leave it on one long line. Then it becomes the reading
agent's problem :-) .

>1st UTF-8, 2nd B64, what was the 3rd ?

SpamAssassin hits were
FORGED_RCVD_HELO RCVD_BY_IP RCVD_NUMERIC_HELO SUBJECT_EXCESS_BASE64
SUBJECT_NOVOWEL

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 10 Apr 2005 17:38:33 +0200

> NO-WS-CTL have been removed. Can people check that the new

It is not.  The "pseudo-consensus" between Charles and me was
to replace msg-id-core by msg-id everywhere, and to fix the
dot-atom-text issue with leading / trailing dots plus dot-dot.

Two (Charles + me) is a bad number, could somebody like you
please volunteer as third for a proper "rough consensus" about
the last open msg-id point, a better name for the "LHS @ RHS"
productions ?  I've interpreted an unrelated article from Bruce
elsewhere as support for "unique @ domain" productions, but
that's obviously dubious,

> I suspect that some minor issues raised by Frank are yet to

The msg-id and dot stuff isn't minor, the former is important,
the latter is erroneous.  Here's the latest ABNF for a msg-id:

| msg-id          =  "<" unique "@" mdomain ">"

| unique          = dot-atom-text / ( DQUOTE unique-quote DQUOTE )
| unique-quote    = ( "." [unique-part] ) /
|                   ( [unique-part] "." ) /
|                   ( [unique-part] unique-literal [unique-part] )
| unique-part     = 1*( atext / "." / unique-literal )
| unique-literal  = "(" / ")" / "," / ; all specials, minus ">",
|                   "[" / "]" / "@" / ; minus DQUOTE, minus "\",
|                   ":" / ";" / "<" / ; minus single ".", plus:
|                   ".." / "\\" / ( "\" DQUOTE )

| mdomain         = dot-atom-text / ("[" address-literal "]")
| address-literal = 1*( %d33-61 /     ; printable ASCII minus
|                       %d63-90 /     ; ">", "[", "\", "]"
|                       %d94-126 /    ; plus "\[", "\\, "\]"
|                       "\[" / "\\" / "\]" )

Some weeks later the "no-pseudo-consensus" arrived at this:

  msg-id = "<" id-local "@" id-domain ">"
  msg-id = "<" msg-local "@" msg-domain ">"
  msg-id = "<" unique "@" mdomain ">"

There it ended with another "pseudo-consensus" to wait for the
next draft and a ruling from the chair (= you).  The latter was
of course a joke, but maybe you can toss a coin - in that case
don't forget Charles' msg-id = "<" id-left "@" id-right ">"

                      Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Sun, 10 Apr 2005 23:19:09 GMT

>dot-atom-text issue with leading / trailing dots plus dot-dot.

Yes, I asked Ken to make that msg-id change, but he hasn't done it yet.
The dot-atom-text issue is noted, but not fixed yet.

>that's obviously dubious,

You can count me in for getting rid of <msg-id-core>, but you can count me
out for any name change for <id-left> and <id-right>.

>|                       %d94-126 /    ; plus "\[", "\\, "\]"

Well not with those names :-( .

But it is still not technically correct. It prevents the msg-id

<"foo.bar.baz"@example.com>

as required (because under RFC 2822 that is indistinguishable from
<[email-masked]>), but it also prevents

<"@.@"@example.com>

and there is no reason to do that (ugly though it may be).

BTW, the "[[Adjacent dots should not be allowed]]" remark in the draft is
not a correct description of the problem.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 11 Apr 2005 16:32:03 +0200

Charles Lindsey wrote:
 
> you can count me out for any name change for <id-left> and
> <id-right>.

That's why we need a third opinion like Alexejs's about this
point, or a better question.  A recent joke on ietf.general:

   /\          /\
__/  \__   ___/  \___/\___   _/\__/\__/\_

consensus  rough consensus   bad question

 [ABNF]
> Well not with those names :-( .

As long as the RHS contains "domain" and the "address-literal"
is an "address-literal" you could beutify it, all productions
starting with "id-" could be a good idea (id-local, id-domain,
etc.)

> It prevents the msg-id
> as required

Yes, that's the idea:
Leading dot or trailing dot or unique-literal <=> quote
No leading/trailing dot and no unique-literal <=> don't quote

> it also prevents

"@" is a "unique literal" => quote.  Working as designed.
"@" is no atext => no dot-atom-text => unquoted is illegal.
Where's the problem ?

> the "[[Adjacent dots should not be allowed]]" remark in
> the draft is not a correct description of the problem.

In the proposed "unique" ABNF adjacent dots are handled by
".." in "unique-literal".  Ugly like hell, but who cares if
it's correct.
                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 12 Apr 2005 11:31:32 GMT

>"@" is no atext => no dot-atom-text => unquoted is illegal.

The problem is that anything with an "@" in it (or various other weird
characters) clearly MUST be quoted, but your syntax does not allow me to
say <"@.@"@example.com> (though it would allow <"@..@"@example.com>).

>".." in "unique-literal".  Ugly like hell, but who cares if

And I suspect it will be even uglier after the "@.@" bug is fixed :-( .
But let us get a working correct syntax first, and then we can see whether
there is a neater way to express it.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Apr 2005 01:57:50 +0200

Charles Lindsey wrote:
 
> anything with an "@" in it (or various other weird
> characters) clearly MUST be quoted,

ACK

> your syntax does not allow me to say <"@.@"@example.com>

NAK

Skipping some details for your msg-id <"@.@"@example.com> I get
example.com    ~ mdomain
"@.@"          ~ ( DQUOTE unique-quote DQUOTE )

Modulo DQUOTE that's @.@ ~ unique-quote

@.@ doesn't start with a dot, it doesn't end with a dot, so
let's try:  @.@ ~ [unique-part] unique-literal [unique-part]

Module @ ~ unique-literal it can match in two different ways: 

@  ~ unique-literal           @. ~ unique-part
.@ ~ unique-part              @  ~ unique-literal

Note the dot "." in unique-part, this should work as desiged.

> though it would allow <"@..@"@example.com>

Any number of dots, zero, one, two, or more.

> it will be even uglier after the "@.@" bug is fixed :-( .

First I want to see a bug before we make it uglier than it is.
It's already ambiguous, it can't get worse, unless it's plain
wrong.
                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 13 Apr 2005 16:04:57 GMT

>Note the dot "." in unique-part, this should work as desiged.

Yes, you have convinced me now.

So there remains the issue of the naming of the syntax rules, which I
think needs a ruling from the Chair.

Also, the wording needs to explain this additional problem (and also the
reason for exlcusion of NO-WS-CONTROL). At the very least, the three
examples given should be changed to:

   <[email-masked]>
   <"ab.cd"@example.com>
   <"ab.\cd"@example.com>

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 13 Apr 2005 22:25:21 +0200

> Yes, you have convinced me now.

Great, we have a msg-id syntax.

> there remains the issue of the naming of the syntax rules,

We're talking about seven names.  So far we agree on msg-id,
and we disagree on names for LHS, RHS, and address-literal.

Maybe we can solve it for the remaining three names without
bothering Alexey, Henry, or Ken:

1 - "unique-quote", the LHS if it must be quoted.  If you hate
    "unique" a very traditional name would be "local".  For
    a post-modern touch we could take "id".  Maybe "quote"
    was too sloppy and "quoted" is better.  Six possibilities:

    unique-quote        local-quote        id-quote
    unique-quoted       local-quoted       id-quoted

2 - "unique-part", the syntactically irrelevant stuff for the
    question "to quote or not to quote".  Obviously we'd want
    the same prefix as in (1).  Maybe "text" is better if we
    don't need it in (3):

    unique-part         local-part         id-part
    unique-text         local-text         id-text

3 - "unique-literal", something that requires quoting.  The
    "literal" is somewhat dubious, 2822 and usefor-03 use it
    for the RHS, but here we are in the LHS   Let's say that
    "literal" was a bad idea.   Depending on (2) "text" could
    be fine.  I also like "special" (as in your "mqspecial"):

    unique-text         local-text         id-text
    unique-special      local-special      id-special

JFTR the three names where we are unable to find a compromise:

4 - "address-literal" vs. "no-fold-literal".  You want the same
    name as in 2822 with a different syntax.  For this reason I
    want a different name reflecting the semantics.

    We've established that the semantics is a "domain-literal"
    in RfC 2822, but that's already used for an 2822-construct
    with CFWS and FWS.   A related source is RfC 2821, there
    the name is "address-literal".  IMHO a typical case of "if
    it quacks like a duck...".

5 - "mdomain" vs. "id-right".  As in (4), you want the name as
    in RfC 2822 with a different syntax.  I want a name that
    reflects the semantics "domain".

    We've spent hours, days, and weeks with the prolem of the
    RHS in a Message-ID, because you said that it's no domain.

    I've shown that that's _not_ what 2822 means.  AFAIK Bruce
    also disagrees with you.  STD 11, RfC 1036, and s-o-1036
    disagree with you.  Abusing foreign namespaces is a serious
    problem.

    If you don't like "mdomain" you could pick "msg-domain" or
    "id-domain".  But "id-right" is OUT as far as I'm concerned.

6 - "unique" vs. "id-left".  A similar case as in (5).  Maybe
    you feel that "unique" is too traditional, and "local" is
    even more traditional.  OTOH it's true, so we could only
    beautify it a bit:

    msg-unique          id-unique
    msg-local           id-local

We can use the prefix "id-" in (6), (5), (3), (2), and (1).
Or the prefix "msg-" in (6), (5), we already have it in msg-id.

> which I think needs a ruling from the Chair.

Alexey as King Canute decreeing that the RHS is NOT a domain ?
I don't think so.

> the wording needs to explain this additional problem

Not necessarily, leading / trailing / adjacent dots aren't new,
it's exactly the same problem as in RfC 2822.

> also the reason for exlcusion of NO-WS-CONTROL

Maybe, but please state them all:  It was never used, it never
worked, it would be a PITA in news-URLs, it wasn't allowed in
any news standard.  More than one line of text, so that we have
a line between these lines saying "2822 GOT IT WRONG - PERIOD."

                           Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Apr 2005 19:42:16 GMT

>bothering Alexey, Henry, or Ken:

Essentially, we either use the same names as RFC 2822 uses, saying that
"the following syntax rules replace the corresponding rules in RFC 2822"
(giving us id-left, id-right, no-fold-quote, no-fold literal, etc), or
else we depart from the RFC 2822 names entirely, except for the msg-id at
the top, in which case your names are as good as any. I don't see that
there is anything in-between.

My preference is to retain the RFC 2822 naming, which accords with the
general principle that we do not change anything in RFC 2822 that we do
not need to change. If our Chair says that we can change these names, then
let it be so. Alexey?

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 24 Apr 2005 16:07:41 +0100

Charles Lindsey wrote:

>not need to change.
I concur with your preference.

>If our Chair says that we can change these names, then
>let it be so. Alexey?
>  
>
If WG members believe that better names should be used, I suggest they 
talk to Pete Resnick first. As far as I remember he has already agreed 
to publish 2822bis.

Alexey

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 25 Apr 2005 16:17:30 GMT

>I concur with your preference.

In that case, we are ready for some syntax. I have given below what I now
think should be in the Message-ID section of USEFOR, including the
necessary syntax changes and rewordings of the descriptive text.

I have also taken the liberty of removing <msg-id-core> in favour of
<msg-id>, which I think we agreed in some earlier discussions on this list
(there will be a few consequential changes elsewhere in USEFOR).

Also, I have suggested a final paragraph regarding use of domains in the
<id-right>, which closes a possible shortcoming in the wording of RFC
2822, as spotted by Frank.

>talk to Pete Resnick first. As far as I remember he has already agreed 

I don't think Pete has gone beyond agreeing in principle to 2822bis. Has
he actually published any Internet Drafts? If so, I will be needing to
comment upon them.

Here follows my suggested Message-ID text:

3.1.3  Message-ID 

   The Message-ID header contains a single unique message identifier.
   This document updates the <msg-id> construct from Section 3.6.4 of
   [RFC2822] so as to ensure that Internet Message Format Message-IDs
   are usable in widely deployed news software.  The global uniqueness
   requirement for <msg-id> in [RFC2822] is to be understood as applying
   across all protocols using such message identifiers, and across both
   Email and Netnews in particular.  A revised syntax for <msg-id> is
   given below, but the requirements and descriptive text from Section
   3.6.4 of [RFC2822] still apply.

|  message-id      =  "Message-ID:" SP [FWS] msg-id [FWS] CRLF
|
|  msg-id          =  "<" id-left "@" id-right ">"
|                     ; maximum length is 250 octets

   id-left         =  dot-atom-text / no-fold-quote

   id-right        =  dot-atom-text / no-fold-literal

|  no-fold-quote   =  DQUOTE
|                        (  "." *mqtext /
|                           *mqtext "." /
|                           *mqtext mqspecial *mqtext )
|                        DQUOTE
|
|  mqtext          =  atext / "." / mqspecial
|
   mqspecial       =  "(" / ")" /      ; same as specials except
                      "<" /            ; "\" and DQUOTE quoted
|                     "[" / "]" /      ; "." doubled and ">" omitted
                      ":" / ";" /
                      "@" / "," /
|                     ".." / "\\" / "\" DQUOTE

   no-fold-literal =  "[" *( mdtext / "\[" / "\]" / "\\" ) "]"
|
   mdtext          =  %d33-61 /        ; The rest of the US-ASCII
                      %d63-90 /        ; characters not including
                      %d94-126         ; ">", "[", "]", or "\"

   The msg-id-core MUST NOT be more than 250 octets in length.

      NOTE: The length restriction ensures that systems which accept
      message identifiers as a parameter when retrieving an article
      (e.g.  [NNTP]) can rely on a bounded length.

|  Observe that <msg-id >includes the < and >.

   Observe also that in contrast to the corresponding header in
|  [RFC2822]
| o the syntax does not allow comments within the Message-ID
|   header,
| o it ensures that no string of characters is quoted if it was already
|   a <dot-atom-text> (it must start or end with a ".", or contain at
|   least one mqspecial),
| o it ensures that no single character is prefixed by a "\" in the
|   form of a <uoted-pair> unless strictly necessary,
| o it excludes all control characters, and
| o there is no possibility for ">" or WSP to occur inside a
|   <msg-id>, whether quoted or not.
|
| This is to simplify processing by relaying and serving agents, and to
| ensure interoperability with existing implementations and compliance
| with [NNTP]. Thus, whereas under [RFC2822] the following <msg-id>s
| would be considered semantically equivalent,

|  <[email-masked]>
|  <"ab.cd"@example.com>
|  <"ab.\cd"@example.com>

   only the first of them is syntactically permitted by this standard,
   and hence a simple comparison of octets will always suffice to
   determine the identity of two <msg-id-core>s.

|  Also note that this updated ABNF applies wherever <msg-id> is used,
|  including the References header discussed in Section 3.2.1 and the
|  Supersedes header discussed in Section 3.2.5.

|    NOTE: It in RECOMMENDED in [RFC 2822] that, for ensuring global
|    uniqueness, the <id-right> be some domain identifier within whose
|    scope the uniqueness of the <id-left> can be guaranteed. When
|    following this recommendation, any <dot-atom-text> or
|    <no-fold-literal> used for the <id-right> are to be interpreted as
|    <domain>s as described in section 3.4.1 of [RFC 2822].

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 27 Apr 2005 12:34:48 +0200

Alexey Melnikov wrote:

>> the general principle that we do not change anything in RFC
>> 2822 that we do not need to change.

> I concur with your preference.

I don't.  The RfC 2822 concept of Message-IDs is "wrong", and
the RfC 1036 concept <unique@domain> is better.  Of course at
least I believe that the RfC 2822 concept is in fact still the
same.  But as far as I can tell it at least Charles thinks that
it's not.  I'm not sure what he believes what an "id-right" is.

> I suggest they talk to Pete Resnick first. As far as I
> remember he has already agreed to publish 2822bis.

I don't recall any discussion about an 2822bis in the past 12
months on the 822-list, but I could post the two proposals for
the _equivalent_ msg-id syntax there (and the reason for this
controversy, "id-right" vs. "id-domain").

I've added an "id-fication" of my proposal below, bye, Frank

~~~ begin ~~~

id-local     = dot-atom-text / ( DQUOTE id-quote DQUOTE )
id-quote     = ( "." [id-text] ) /
               ( [id-text] "." ) /
               ( [id-text] id-special [id-text] )

id-text      = 1*( atext / "." / id-special )
id-special   = "(" / ")" / "," /       ; all specials, minus ">",
               "[" / "]" / "@" /       ; minus DQUOTE, minus "\",
               ":" / ";" / "<" /       ; minus single ".", plus:
               ".." / "\\" / ( "\" DQUOTE )

id-domain    = dot-atom-text / ("[" id-literal "]")
id-literal   = 1*( %d33-61 /           ; printable ASCII minus
                   %d63-90 /           ; ">", "[", "\", "]"
                   %d94-126 /          ; plus "\[", "\\, "\]"
                   "\[" / "\\" / "\]" )
~~~ end ~~~

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 27 Apr 2005 11:53:11 +0200

Charles Lindsey wrote:

~~~ begin quoted ABNF ~~~
message-id      =  "Message-ID:" SP [FWS] msg-id [FWS] CRLF

msg-id          =  "<" id-left "@" id-right ">"
                   ; maximum length is 250 octets

no-fold-quote   =  DQUOTE
                      (  "." *mqtext /
                         *mqtext "." /
                         *mqtext mqspecial *mqtext )
                      DQUOTE

mqtext          =  atext / "." / mqspecial

mqspecial       =  "(" / ")" /      ; same as specials except
                   "<" /            ; "\" and DQUOTE quoted
                   "[" / "]" /      ; "." doubled and ">" omitted
                   ":" / ";" /
                   "@" / "," /
                   ".." / "\\" / "\" DQUOTE

mdtext          =  %d33-61 /        ; The rest of the US-ASCII
                   %d63-90 /        ; characters not including
                   %d94-126         ; ">", "[", "]", or "\"
~~~ end of quoted sytax ~~~

Is that as you want it ?  I'm not sure about Alexey's external
expert for 2822bis, so I think the most simple solution to get
an expert review for the two proposals is to post them on the
rfc-822 mailing list.

> The msg-id-core MUST NOT be more than 250 octets in length.

s/msg-id-core/msg-id/g

>|  Supersedes header discussed in Section 3.2.5.

IMHO that's obvious and needs no "note", excl. References: the
two other cases (Supersedes: and Control: cancel) don't exist
in mail.

BTW, in Control: you have the same syntax problem as in the
References:, you separate the arguments by an _optional_ [FWS]:

Control: cancel<a@b><c@d>
Control: newgroupthis.is.new
Control: rmgroupthis.is.old

You need a mandatory FWS in 3.2.4.  "value" is apparently not
defined in usefor-03 or 2822.  "token" is apparently also not
defined in usefor-03 or 2822.

Did anybody try an ABNF checker on usefor-03 ?  (I didn't)

>| NOTE: It in RECOMMENDED in [RFC 2822] that, for ensuring
>| global uniqueness, the <id-right> be some domain identifier

It's unnecessary to quote that RECOMMENDATION, least of all the
"some domain identifier".  Out of its original very convoluted
RfC 2822 context this quote is in fact _worse_ than RfC 2822.

RfC 1036 or s-o-1036 is _much_ better than this sad parody of
a Message-ID.  Usenet is better off without this idea, it is
harmful, it should never become an RfC.

IIRC we had a "pseudo-consensus" (= you and me) about domain-
literals in addresses, Message-IDs, and Path-identifiers, i.e.
say something like STD 11 without shouting:

| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

Apparently that didn't make it yet into usefor-03 or usepro-03,
it's roughly equivalent to a SHOULD NOT mentioning the "domain"
in all "addr-spec" found in any From: / Sender: / Reply-To: /
Approved:, the "id-right" (your 2822-terminology) of a msg-id,
the "path-identity", do we need it anywhere else ?  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 28 Apr 2005 15:18:48 GMT

>I don't.

But you asked for someone to come along and provide a casting vote to
settle the difference between you (wanting <unique>@<domain>) and me (wanting
to retain <id-left> and <id-right>). Now you have it, and it puts you in a
minority (even if it does not amount to a ruling from the Chair). You are
the only person wanting <unique>@<domain>.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 28 Apr 2005 15:03:19 GMT

>message-id      =  "Message-ID:" SP [FWS] msg-id [FWS] CRLF

...........

>Is that as you want it ?

Yes. Do you see any technical error in it?

>  I'm not sure about Alexey's external

I don't think there is current activity on 2822bis. As soon as there is, I
will be trying to persuade them into adopting our syntax, or preferebaly
some less bizarre subset of it. Their present msg-id definition should
just go into their obs-syntax. But that is a battle for another day and
another place.

>s/msg-id-core/msg-id/g

Oops!

>IMHO that's obvious and needs no "note",

It's in the present text. I would have no worries if Ken decided to take
it out.

>Control: cancel<a@b><c@d>

Hold on! You aren't allowed to cancel more than one article at a time.
Yes, I know CNews does it, but this WG decided long ago not to allow it,
since most other serving agents don't accept it.

>Control: rmgroupthis.is.old

But yes, you have spotted a real bug there (but fortunately the error is
not repeated in the syntax of the actual <control-command>s in USEPRO).

But whilst we are here, there are two other errors in the Control syntax.

A. The FWS should be CFWS in all places.

The WG agreed early on that comments should be acceptable in all places
allowed by RFC 2822, but on a "MUST accept, do not generate yet" basis.
Later on, we agreed that they should be disallowed wherevoer there was a
severe performance penalty, so they were removed from Newsgroups,
Message-ID, Path, Followup-To and Distribution (these were intended to be
permanent exclusions, not just until "yet" happened).

But it was never agreed for Control, because Control headers are so rare
that performance issues can be neglected.

B. s/control-message/control-command/

This is to accord with a change I made in USEPRO. The problem is that the
term "control message" is already defined to mean the whole article
containing a Control header, and to have the syntactic element
<control-message> meaning something different seemed a bad idea.

So I believe the complete syntax for Control headers should be:

   control         =  "Control:" SP [CFWS] control-command [CFWS] CRLF

   control-command =  verb *( CFWS argument )

   verb            =  token

   argument        =  value

On top of that, a "do not generate comments yet" wording would be in
order, as for the References header, but I would prefer a generic
statement to that effect covering all headers inherited from RFC 1036.

>...  "value" is apparently not

<value>, <token> and <parameter> are all defined in RFC 2045, and used at
various places in USEFOR. This needs to be stated somewhere, but there is
more to it than that because RFC 2045, being RFC 822 based, does not tell
you where to put the [CFWS]s in them, so we need some wording to cover
that.

Also, in Injection-Info, where it says

   post-host-param =  "posting-host" "=" host-value

it actually means

   post-host-param =  [CFWS] "posting-host" [CFWS] "=" [CFWS] host-value [CFWS]

and similarly for the other <*-param>s.

So that needs to be covered by explicit syntax or suitable verbiage.

>RfC 2822 context this quote is in fact _worse_ than RfC 2822.

There is a problem in RFC 2822 (which you yourself spotted) in that there
is wording in 3.4.1 to the effect that a <domain-literal> is meant to be
an IP address (whether IPv4 or IPv6 or any other IPvxx), in spite of a
syntax apparently allowing much more, but they omitted to say the same
thing about a <no-fold-literal>.

The text I wrote was intended to plug this whole, but it was only a NOTE,
so had no normative effect. If you still want this hole plugged, then
please propose an alternative text.

>| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.

Yes, but there is more to say than that, because even a <domain-literal>
is discouraged (does RFC 2822 still say that?) you want even more
discouragement for other than IP addresses inside them, and you still need
to extend it to <id-right>s.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 29 Apr 2005 02:01:51 +0200

Charles Lindsey wrote:

> But you asked for someone to come along and provide a
> casting vote

True.  I wasn't happy with how Alexey did it, no indication
that he understood why we agree on a syntax but disagree on
the stupid names of the productions.  As chair he's supposed
to handle such obscure problems with tact.

> You are the only person wanting <unique>@<domain>.

That's not the point, I'm the person who seriously does not
like "id-right", I think that your idea of "id-right" is not
the "id-domain" in my last proposal.

If you like to reopen negotiations, you can have "id-left".

The critical part for Usenet is the RHS with a domain.  The
LHS is then only a problem of *the* domain owner.  For your
"id-right" that's very unclear.
                               Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 29 Apr 2005 03:49:55 +0200

> Yes. Do you see any technical error in it?

No, I just wanted to be sure that I can quote it as is.

> I will be trying to persuade them into adopting our
> syntax, or preferebaly some less bizarre subset of it.

The excluded ">" is bizarre, but allowing it elsewhere would be
a pain for gateways.  This syntax _is_ the Message-ID for mail
and news, bizarre or not.

I thought about putting it into an I-D, "updates 2822", ready,
problem solved.

> Hold on! You aren't allowed to cancel more than one

Sorry, I wrote it after the very similar References issue.

> A. The FWS should be CFWS in all places.

I thought the server folks don't want CFWS in their headers,
because they don't want to waste time to parse comments.

> The WG agreed early on that comments should be acceptable
> in all places allowed by RFC 2822

Especially where stupid users do stupid things, but Control ?

> Control headers are so rare that performance issues can be
> neglected.

Okay, if you say so.  Convince Russ that it's a good idea.

> control   =  "Control:" SP [CFWS] control-command [CFWS] CRLF

Often you have the leading / trailing [CFWS] in the "inner"
rule with shorter lines, i.e.

  control         =  "Control:" SP control-command CRLF
  control-command =  [CFWS] verb *( CFWS argument ) [CFWS}

Of course irrelevant; I only see it when I try to quote it.

> On top of that, a "do not generate comments yet" wording
> would be in order, as for the References header

If you think that comments are stupid, and they are, and only
needed for users who trust that the rules are everywhere the
same, then using [FWS] and FWS without any additional wording
is much clearer than [CFWS] and CFWS with a rule to pray not
yet use comments in an "administrative" header like Control.

> I would prefer a generic statement to that effect covering
> all headers inherited from RFC 1036.

That's a trend, you love to say A in syntax, and then to add
long qualifications which are near to NOT A.  I'd just say
NOT A in syntax without qualification, and be done with it.

> <value>, <token> and <parameter> are all defined in RFC 2045

Yes.  So far I didn't know that usefor-03 implicitly includes
all 2045 terms.  I only knew that it includes 2822 minus obs,
and of course 2234bis.

2045 is older than 2234.  IMHO it's better to copy (and check)
what you need, instead of implicitly importing it.  Checking:

     token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                or tspecials>

Whatever that is, it's no proper ABNF.  So why did Keith do it
in 3834, Bruce must have seen this, I'm stunned.  2231 doesn't
fix it.  We shouldn't import this quasi-ABNF, even if Bruce
promises to let it pass.

> There is a problem in RFC 2822 (which you yourself spotted)

A _real_ problem in 2822 ?  So far I tended to hallucinate
problems, but the worst I'm sure of was an "I don't like it".

> If you still want this hole plugged, then please propose an
> alternative text.

That's simple, just say "id-domain" and "id-literal" _without_
additional wording.  Or say "address-literal".  Not the unclear
"id-right" and "no-fold-literal" stuff, where nobody knows what
it's supposed to mean.  Or add a note with this effect:

Note: id-right is a domain, and no-fold-literal is the special
case of a domain-literal (a.k.a. address-literal, see RfC 2821)

> Yes, but there is more to say than that, because even a
> <domain-literal> is discouraged (does RFC 2822 still say
> that?) you want even more discouragement for other than IP
> addresses inside them, and you still need to extend it to
> <id-right>s.

More to say ?  That statement is perfectly clear, and we have
serious technical reasons why we want it.  No, AFAIK RfC 2882
does not say so, otherwise we wouldn't need it in usefor-xx.

                           Bye, Frank

---

From: Russ Allbery <[email-masked]>
Date: Thu, 28 Apr 2005 19:01:36 -0700

> Okay, if you say so.  Convince Russ that it's a good idea.

RFC 2822 doesn't say anything about Control headers, for obvious reasons.
What are we gaining by adding comments to the header and breaking existing
software?

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 29 Apr 2005 15:48:22 GMT

>What are we gaining by adding comments to the header and breaking existing

Consistency with conventions for headers elsewhere. Users don't want to
have to remember which headers allow comments and which don't (except
where there are strong and permanent reasons to the contrary, such as
performance issues that are never going to go away).

Sooner or later, some enterprising person is going to write

Control: cancel <[email-masked]> (unapproved article in moderated group)

and will be most miffed if it is rejected or doesn't work.

Yes, it may not work with many current servers, but there is no reason why
it should not work long term. It is not rocket science to preprocess all
headers to remove all comments and foldings before acting upon them.

Anyway, the WG has never asked for this particular comment to be forbidden
(and it _did_ decide very early on that comments were normally to be
accepted everywhere, but maybe not generated "yet"). It was not forbidden
in any of the earlier drafts, so it is premature for USEFOR to have
removed it.

If the WG wants this change, then it ought to be discussed first.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 29 Apr 2005 16:08:38 GMT

>all 2045 terms.  I only knew that it includes 2822 minus obs,

It needs to be stated somewhere.

>in 3834,

Because that is exactly what RFC 2045 says. It even appeared (but not
normatively) in my old draft-13.

But the real problems are <parameter> and <value>. In draft-13, I actually
had (simplifying slightly, because there were also RFC 2231
complications):

parameter = [CFWS] token [CFWS] "=" value
value     = [CFWS] token [CFWS] / quoted-string

(again, not normatively)

But I was forbidden from having that stuff incorporated into USEFOR. As a
result, USEFOR does not adequately explain where [CFWS] can appear in
Injection-Info.

>problems, but the worst I'm sure of was an "I don't like it".

OK, if you don't want it fixed, let it go. But just using <domain> in
place of <id-right> will not fix it either, without further verbiage.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Fri, 29 Apr 2005 12:47:38 -0400

> If the WG wants this change, then it ought to be discussed first.

There you go again.

Charles, the only meaning of "change" that makes sense is a change
from current published standards and practice. I believe you have once
again used it to mean "an edit to the draft."  Please stop it.

If something appeared in the draft that was never discussed in the WG,
it ought to be removed.

Removing such things do not need to be discussed first, because removing
them is not a change, having them in is a change.

The draft is fluid, it isn't a big deal to delete and edit words.

Modifying servers to parse comments in control headers is a big
deal.

No matter what ideas of future scenarios anyone can conjure up, unless it
is a current request, or existing practice, or a forseeable need (not
a "would be nice.") it ought to be cut from the drafts.  It is outside
the charter.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 30 Apr 2005 03:32:34 +0200

Charles Lindsey wrote:

> OK, if you don't want it fixed, let it go.

I've proposed many ways to fix it, e.g. by clear names for
the msg-id productions, or the last proposal was this note:

| Note: id-right is a domain, and no-fold-literal is the
| special case of a domain-literal (a.k.a. address-literal,
| see RfC 2821)

Plus a general note about avoiding domain-literal whereever
possible, i.e. the same idea as in STD 11.

> But just using <domain> in place of <id-right> will not
> fix it either, without further verbiage.

IBTD.  If the msg-id is broken in relation to 1036 / s-o-1036
usefor-xx MUST NOT fly as far as I'm concerned.  Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 30 Apr 2005 03:11:26 +0200

Charles Lindsey wrote:

> it ought to be discussed

Kill all CFWS in pre-2045 news-only-headers where it doesn't
contradict 2045 / 2822.  For new headers like User-Agent or
Injection-Info adopt common practice or 2045 / 2822 style.

I know that it's not what the WG once wanted, but you asked.

                     € 0.02, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 30 Apr 2005 05:14:59 +0200

Charles Lindsey wrote:

>> So far I didn't know that usefor-03 implicitly includes
>> all 2045 terms.  I only knew that it includes 2822 minus
>> obs, and of course 2234bis.

> It needs to be stated somewhere.

It is, I was blind.  But we cannot use this pseudo-ABNF, it has
to be fixed for the three (?) 2045 terms needed in usefor-xx:

value, token, parameter, anything else ?

> It even appeared (but not normatively) in my old draft-13.

Yes, the "collected ABNF" was nice, but I never checked all
the details in 2003 for draft 7 and its "last last last call".

Fortunately Bruce was an inspiration how to get these details
right, but that was later from my POV.

1) value = token / quoted-string

No "value =" in 2822, no "value :=" in 2231, so that should
be no problem as soon as you have a valid "token" elsewhere.

2) parameter = attribute "=" value

Trouble, "parameter" is redefined in 2231.  While I'd love to
nullify 2231 that's not excatly realistic.  Maybe we could
nominate 2231 by a joint agreement of LTRU and USEFOR as the
most painful RfC. :-(  Better remove the one "archive-param".

2a) attribute = token

Same problem as with "parameter", but you only (?) need it
indirectly for "archive-param".  In theory it's very easy to
translate the 2231 gibberish to proper ABNF:

  attribute      = 1*attribute-char
  attribute-char = <any (US-ASCII) CHAR except SPACE, CTLs,
                     "*", "'", "%", or tspecials>

A proper subset of US-ASCII, "tspecials".defined in 2045, and
2045 took it from STD 11.  But not the same as the "specials"
in 2822.  I need some ASCII-subset tools. <sigh>

3) token = 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials>

Okay, that's the same as attribute-char plus "*", "'", "%".

> value     = [CFWS] token [CFWS] / quoted-string

Where have you found these [CFWS] ?  Because 2045 mentions 822
and its comments, and 2822 claims to update 822 ?

> But I was forbidden from having that stuff incorporated into
> USEFOR.

Do you have a Message-ID for this obscure decree ?  I see the
potential problem with the optional CFWS, but otherwise your
"value" is just a copy from 2045.  Okay, "parameter" is a bad
case of 2231, see above.

> as a result, USEFOR does not adequately explain where [CFWS]
> can appear in Injection-Info.

Okay, then let's reinvent the wheel, no 2231 and no CFWS.  Bye