headers
Frank Ellermann | 1 Jan 2006 01:44
Picon
Picon

Control: cancel ABNF bug


Hi, there's apparently a subtle bug in the -06 ABNF.
We want (USEPRO 6.3):

      control-command     =/ Cancel-command
      Cancel-command      = "cancel" Cancel-arguments
      Cancel-arguments    = FWS msg-id [FWS]

That's your  msg-id = "<" id-left " <at> " id-right ">"
(same as my  msg-id = "<" id-unique " <at> " id-domain ">" ).

But USEFOR and 2045 (with Ned's pending erratum) say:

      control-command =  verb *( [FWS] argument )
      verb            =  token
      argument        =  value

      value := token / quoted-string
      token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                  or tspecials>
      tspecials :=  "(" / ")" / "<" / ">" / " <at> " /
                    "," / ";" / ":" / "\" / <"> /
                    "/" / "[" / "]" / "?" / "="
                    ; Must be in quoted-string,
                    ; to use within parameter values

In other words Control: cancel <whatever <at> example> is not
allowed, and we certainly don't want to quote a <msg-id>:

               Control: cancel "<whatever <at> example>"
(Continue reading)

Permalink | Reply | 36 comments |
headers
Harald Tveit Alvestrand | 1 Jan 2006 14:57
Picon

Re: IANA considerations


--On 28. desember 2005 19:41 +0000 Charles Lindsey <chl <at> clerew.man.ac.uk> 
wrote:

>
> In <4E1927EA4BCAE0EFDB80BE29 <at> B50854F0A9192E8EC6CDA126> Harald Tveit
> Alvestrand <harald <at> alvestrand.no> writes:
>
>> Grumble. The HTTP and Mail documents both give full templates per
>> header,=20 and as you say, this makes for a very long document (easy to
>> produce, just=20 tedious). I like the idea of not making -usefor depend
>> on this.
>
> Well looking at the registries IANA have actually constructed
> (http://www.iana.org/assignments/message-headers/perm-headers.html and
> http://www.iana.org/assignments/message-headers/prov-headers.html), they
> have only taken the bare bones of those documents - essentially what Ken's
> table proposed), so I think that is all we are obliged to provide. In
> fact, they haven't even included the 'Status' and 'Author/Change
> controller' fields at all, which I find odd. And for sure, if we want any
> "related information" to be attached to some header, we will need to say
> so explicitly in out IANA Considerations.

Note that the registry points to the documents that contain the complete 
registration templates. I don't think we can break the rules by not 
submitting the templates.

(The question of how IANA maintains registries is a completely different 
subject.)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Frank Ellermann | 2 Jan 2006 13:22
Picon
Picon

Re: IANA considerations


Harald Tveit Alvestrand wrote:

> the registry points to the documents that contain the complete
> registration templates. I don't think we can break the rules
> by not submitting the templates.

Okay, so either a separate document (my preference, same style
as for mail and http), or complete templates in the core spec.
(ugh).  It's a piece of cake to create the former, but I don't
want to waste time for it if we then pick the latter strategy.

With split documents an outline for the core spec. would be:

IANA Considerations

  The news header fields specified or obsoleted by this memo
  are listed separately in [draft-ietf-usefor-hdrreg-00] with
  the registration templates for the IANA registry of header
  fields.
[...]

Informative References
[...]
  [draft-ietf-usefor-hdrreg-00] Registration of news header
  fields specified or obsoleted by [RFC XXXX] (this memo).

xml2rfc has some magic supporting self-references [RFC XXXX],
and draft-ietf-usefor-hdrreg-00 would be an informational RFC.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Murchison | 2 Jan 2006 15:46
Picon

Re: IANA considerations


Harald Tveit Alvestrand wrote:
> 
> 
> --On 22. desember 2005 08:17 -0500 Ken Murchison <murch <at> andrew.cmu.edu> 
> wrote:
> 
>>>    NNTP-Posting-Date netnews deprecated IETF
>>>    Also-Control netnews obsoleted IETF
>>>    See-Also netnews obsoleted IETF
>>>    Article-Names netnews obsoleted IETF
>>>    Article-Updates netnews obsoleted IETF
>>>
>>> A proper reference for the last 4 would be Son-of-1036, which we propose
>>> to refer to in any case. The 1st two have no published definition that I
>>> know of apart from the source code of INN. However, they are both much
>>> used, and we have explicitly deprecated their continued use in USEFOR. I
>>> think it would still be proper to describe IETF as the "Change
>>> Controller" (but not as Author, obviously).
>>
>> If s-o-1036 actually defines a header, then I think we can probably
>> register it.  If there is no definition anywhere that we can reference,
>> then how can we register it?  I certainly don't want to add ABNF to our
>> doc for headers that are dead.
>>
>> Harald, any thoughts?
> 
> Grumble. The HTTP and Mail documents both give full templates per 
> header, and as you say, this makes for a very long document (easy to 
> produce, just tedious). I like the idea of not making -usefor depend on
(Continue reading)

Permalink | Reply | 5 comments |
headers
Harald Tveit Alvestrand | 2 Jan 2006 17:18
Picon

Re: IANA considerations


--On mandag, januar 02, 2006 09:46:58 -0500 Ken Murchison 
<murch <at> andrew.cmu.edu> wrote:

>> Grumble. The HTTP and Mail documents both give full templates per
>> header, and as you say, this makes for a very long document (easy to
>> produce, just tedious). I like the idea of not making -usefor depend on
>> this.
>
> Do we really have to use the same format as given by the template, or
> just provide the same information as specified by the template?

I don't see much leeway in RFC 3864 section 3 and 4:

3.  Registry Usage Requirements

   RFCs defining new header fields for Internet mail, HTTP, or MIME MUST
   include appropriate header registration template(s) (as given in
   Section 4.2) for all headers defined in the document in their IANA
   considerations section.  Use of the header regi stry MAY be mandated
   by other protocol specifications, however, in the absence of such a
   mandate use of the registry is not required.

4.  Registration Procedure

   The procedure for registering a message header field is:

   1.  Construct a header field specification

   2.  Prepare a registration template
(Continue reading)

Permalink | Reply | 2 comments |
headers
Harald Tveit Alvestrand | 2 Jan 2006 17:25
Picon

Re: Control: cancel ABNF bug


--On søndag, januar 01, 2006 01:44:59 +0100 Frank Ellermann 
<nobody <at> xyzzy.claranet.de> wrote:

> For section 3.2.5 (changing only its <argument>):
>
>       control-command =  verb *( [FWS] argument )
>       verb            =  token
>       argument        =  1*VCHAR
>
> Or directly  argument = 1*(%x21-7E)  without the VCHAR.

Personal opinion: I like the last version - simple and self-contained.

Q: Is there no case where a control: message needs a space?

>
>                         Bye, Frank
>
> P.S.:  why on earth do they need more than 10 months to
> publish an erratum submitted by one of the 2045 authors ?

I sure don't know - when it was my problem, every time they asked, they 
said that the IETF had told them publishing RFCs was more important.....
Permalink | Reply | 32 comments |
headers
Ken Murchison | 2 Jan 2006 18:17
Picon

Re: IANA considerations


Harald Tveit Alvestrand wrote:
> 
> 
> --On mandag, januar 02, 2006 09:46:58 -0500 Ken Murchison 
> <murch <at> andrew.cmu.edu> wrote:
> 
>>> Grumble. The HTTP and Mail documents both give full templates per
>>> header, and as you say, this makes for a very long document (easy to
>>> produce, just tedious). I like the idea of not making -usefor depend on
>>> this.
>>
>> Do we really have to use the same format as given by the template, or
>> just provide the same information as specified by the template?
> 
> I don't see much leeway in RFC 3864 section 3 and 4:

So, what is the decision of the chair regarding the format and location 
of the IANA header registry entries?

--

-- 
Kenneth Murchison
Systems Programmer
Carnegie Mellon University
Permalink | Reply | 1 comment |
headers
Russ Allbery | 2 Jan 2006 19:07
Picon
Favicon
Gravatar

Re: Control: cancel ABNF bug


Harald Tveit Alvestrand <harald <at> alvestrand.no> writes:

> Personal opinion: I like the last version - simple and self-contained.

> Q: Is there no case where a control: message needs a space?

Like:

    Control: newgroup example.moderated moderated

?  Or am I misunderstanding?

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply | 29 comments |
headers
Frank Ellermann | 2 Jan 2006 19:16
Picon
Picon

Re: Control: cancel ABNF bug


Harald Tveit Alvestrand wrote:

>>       control-command =  verb *( [FWS] argument )
>>       verb            =  token
[...]
>>              argument = 1*(%x21-7E)
{...]

> Is there no case where a control: message needs a space?

That would be ambiguous with the [FWS].  For new/rm/mvgroup
it's <newsgroup-name> (like FQDN plus underscore, no space).

Dito for checkgroups, adding "!" for excluded scopes, and a
serial number "#" 1*DIGIT

For cancel it's <msg-id> (no space even for 2822 NO-WS-CTL).

For ihave / sendme it's <relayer-name> (= <path-identity> ).
Whatever we do with barewords and #1047, we shouldn't allow
a space within a <path-identity> :-)

The obsolete 1036 commands version and sendsys have no
argument.  The "archaeological" whogets and senduuname are
unspecified, apparently no argument for senduuname and a
<newsgrup-name> for whogets.  No spaces within arguments.

>> P.S.:  why on earth do they need more than 10 months to
>> publish an erratum submitted by one of the 2045 authors ?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Ellermann | 2 Jan 2006 19:38
Picon
Picon

Re: Control: cancel ABNF bug


Russ Allbery wrote:

> Or am I misunderstanding?

Yes, not FWS between arguments, WSP within an argument.  BTW,
is this [FWS] as you want it, or should it be 1*WSP ?  Would...

Control: newgroup 
 new.group.example
 moderated

...work anywhere ?  Everywhere ?  Bye, Frank
Permalink | Reply | 28 comments |

Gmane