9 May 2009 19:15
Julien ÉLIE <julien <at> trigofacile.com>
2009-05-09 17:15:53 GMT
2009-05-09 17:15:53 GMT
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).