Tr: Injection-Info

Just for your information (from news.software.nntp).

It is true that
    "Injection-Info: nowhere;posting-host=localhost:::1"
is not pretty to read and "posting-host" could have been
shortened to "host"...

And Injection-Date: a sub-field of Injection-Info: (but maybe
it was done this way because it was easier to parse in order
to obtain the date?).

Julien

----- Message d'origine ----- 
De : "D. Stussy" <spam <at> bde-arc.ampr.org>
Groupes de discussion : news.software.nntp
Envoyé : mercredi 29 avril 2009 00:55
Objet : Re: Injection-Info

> "Russ Allbery" <rra <at> stanford.edu> wrote in message
> news:87r5zcu17j.fsf <at> windlord.stanford.edu...
>> http://www.eyrie.org/~eagle/usefor/drafts/draft-ietf-usefor-usefor-12.txt
>> has the specification.  (You can also get that I-D from a bunch of other
>> places, including direct from the IETF, of course.)
>
> Q:  Why is "Injection-Date" a separate header and not a sub-field of
> "Injection-Info"?
>
> Also, under "Injection-Info" syntax:
>
> host-value      =  dot-atom-text / IPv4address / IPv6address /
>                      (dot-atom-text ":" ( IPv4address / IPv6address ))
>
> If specifying both a hostname (as "dot-atom-text") and an IP address, why
> not make the IP address a CWFS comment?  I really don't like that colon as
> IPv6 address literals may start with a double-colon, and the effective
> triple-colon would look ugly.  (OK, so maybe it shouldn't happen except for
> localhost since IPv4-mapped and IPv4-compatible IPv6 addresses shouldn't be
> sources, but the syntax doesn't forbid such.)
>
> e.g.  "Injection-Info: nowhere;posting-host=localhost:::1"
> vs.   "Injection-Info: nowhere;posting-host=localhost (::1)"
>
> BNF:  "/", not "|" in specifying an option (choose one of)?  Hmmmm.
>
> In the "Injection-Info" parameters, do we really have to say "posting-host"
> instead of just "host", and "posting-account" instead of just "account" (or
> "acct")?  Isn't that understood from the header itself?
>
> ------
> Another thought:  If "Supersedes" must not exist with "Control" functions,
> why not make the supersedes function itself a control function (i.e.
> "supersedes" becomes a verb)?  Won't that will prevent the problem?  This
> way, it also parallels the "cancel" operation (if that's still to be
> supported).  For backwards compatibility only, allow the separate header
> (possibly having a server rewrite any "Supersedes: <data>" header into
> "Control: supersedes <data>", thus also removing any other "Control:"
> header).