headers
Julien ÉLIE | 1 Jun 2009 10:23
Favicon

Arguments to checkgroups control messages


Hi,

chkscope = 1*( 1*WSP ["!"] newsgroup-name )

These lines are equivalent:

    Control: checkgroups de !de.alt #2009021301
    Control: checkgroups !de.alt de #2009021301

Maybe it should be highlighted in the text (so that it is not
the last matching entry that prevails for each newsgroup).

By the way, it should also be said that every newsgroup should/must
be listed only *once* in a checkgroups.  I did not find the
information stated clearly.

--

-- 
Julien ÉLIE

« L'atour est fiel aux Huns valides. »
Permalink | Reply | 6 comments |
headers
Russ Allbery | 1 Jun 2009 23:18
Picon
Favicon
Gravatar

Re: Missing RFC editor commit


Julien ÉLIE <julien <at> trigofacile.com> writes:

>           bar.isp.example was not a correct &lt;path-identity> for that
> -          source but simply that that identity did not match the
> +          source but simply that the identity did not match the
>           expectations of foo-news.)</t>
>
> Isn't there something better in English to say "that" in that case?
> Because we have in the same sentence "that source" and "the identity";
> it would be better to keep the meaning of "that identity".

It's a style thing, and I assume the RFC Editor uses a fairly
conservative English style that avoids all doubled words even when
grammatically correct.  "the" is sufficiently specific in English to
serve as "that" in a pinch, so I was okay with the change.

>  <at>  <at>  -986,8 +1010,7  <at>  <at> 
>             If it implements one of the mechanisms described in <xref
>             target="history" />, this means that it MUST reject any
>             article whose date falls outside the cutoff interval since it
> -            won't know whether such articles had been accepted previously
> -            or not.</t>
> +            won't know whether or not such articles had been accepted previously.</t>

> Is "or not" necessary?  Isn't "it won't know whether such articles" enough?
> (It happens twice in the text.)

It's not strictly necessary, but it doesn't hurt either.  It's better
than what it was, which had the "or not" at the end of the sentence.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Jun 2009 23:20
Picon
Favicon
Gravatar

Re: Arguments to checkgroups control messages


Julien ÉLIE <julien <at> trigofacile.com> writes:

> chkscope = 1*( 1*WSP ["!"] newsgroup-name )
>
> These lines are equivalent:
>
>    Control: checkgroups de !de.alt #2009021301
>    Control: checkgroups !de.alt de #2009021301
>
> Maybe it should be highlighted in the text (so that it is not
> the last matching entry that prevails for each newsgroup).
>
> By the way, it should also be said that every newsgroup should/must
> be listed only *once* in a checkgroups.  I did not find the
> information stated clearly.

Hm -- I agree with both of these, but it's likely to go through another
round of AD or chair approval since it's beyond what the RFC Editor can
just change.  I'm not sure if the change is worth it, but I can prepare
a diff if people feel like it is.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply | 5 comments |
headers
Julien ÉLIE | 2 Jun 2009 19:10
Favicon

Re: Arguments to checkgroups control messages


First of all, thanks, Russ, for your response on the RFC
editor's commit.

>> chkscope = 1*( 1*WSP ["!"] newsgroup-name )
>>
>> These lines are equivalent:
>>
>>    Control: checkgroups de !de.alt #2009021301
>>    Control: checkgroups !de.alt de #2009021301
>>
>> Maybe it should be highlighted in the text (so that it is not
>> the last matching entry that prevails for each newsgroup).
>>
>> By the way, it should also be said that every newsgroup should/must
>> be listed only *once* in a checkgroups.  I did not find the
>> information stated clearly.
>
> Hm -- I agree with both of these, but it's likely to go through another
> round of AD or chair approval since it's beyond what the RFC Editor can
> just change.  I'm not sure if the change is worth it, but I can prepare
> a diff if people feel like it is.

I believe it is worthwhile... because of this mere sentence
on news.software.nntp <news:h025go$vin$1 <at> aux.snarked.org>:

  >> Besides, the patch totally breaks "checkgroups !hr.admin hr".
  >
  > Which, as I understand it, is incorrect - as exclusion patterns must trail.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Julien ÉLIE | 5 Jun 2009 07:39
Favicon

Case-sensitivity in newsgroup names and message-IDs


Hi,

Following a discussion between Mateusz Viste, Russ Allbery, Urs Janßen
and me on news.software.nntp (see <bsjlf6-frq.ln1 <at> mail.viste-family.net>),
it appears there is a problem with case-sensitivity of a newsgroup name
and a message-ID.

The following paragraph from RFC 3977 applies:

3.1.  Commands and Responses

   Keywords are case insensitive; the case of keywords for commands MUST
   be ignored by the server.  Command and response arguments are case or
   language specific only when stated, either in this document or in
   other relevant specifications.

In practice, news servers implement:

GROUP news.software.nntp
211 3219 149 6892 news.software.nntp

GROUP news.software.NNTP
411 No such group news.software.NNTP

that is to say that news.software.nntp and news.software.NNTP are *not*
the same newsgroup.  The same behaviour occurs if I use:

Newsgroups: news.software.NNTP
(Continue reading)

Permalink | Reply | 3 comments |
headers
Julien ÉLIE | 5 Jun 2009 07:39
Favicon

Re: Arguments to checkgroups control messages


Hi all,

>>> These lines are equivalent:
>>>
>>>    Control: checkgroups de !de.alt #2009021301
>>>    Control: checkgroups !de.alt de #2009021301
>>>
>>> Maybe it should be highlighted in the text (so that it is not
>>> the last matching entry that prevails for each newsgroup).

The problems comes from that, in RFC 3977 (NNTP), when something
is matched, it is always because of the last entry:

  4.2.  Wildmat Semantics

   A wildmat is tested against a string and either matches or does not
   match.  To do this, each constituent <wildmat-pattern> is matched
   against the string, and the rightmost pattern that matches is
   identified.  If that <wildmat-pattern> is not preceded with "!", the
   whole wildmat matches.  If it is preceded by "!", or if no <wildmat-
   pattern> matches, the whole wildmat does not match.

   For example, consider the wildmat "a*,!*b,*c*":

   o  The string "aaa" matches because the rightmost match is with "a*".

   o  The string "abb" does not match because the rightmost match is
      with "*b".
(Continue reading)

Permalink | Reply | 3 comments |
headers
Julien ÉLIE | 5 Jun 2009 20:21
Favicon

multipart/mixed with checkgroups


Hi,

If multipart/mixed is used with checkgroups, it breaks all existing
implementations because the body of the message should currently
consist only of newsgroups.

However, multipart/mixed can be used with newgroup messages.  And
application/news-groupinfo can lack the "For your newsgroups file:"
line.

Wouldn't it be useful to declare that multipart/mixed SHOULD NOT be
used with checkgroups but that an implementation SHOULD process
checkgroups control articles as MIME messages and search for
an application/news-checkgroups entity?

It would then allow to eventually have the possibility to send
multipart checkgroups and therefore provide a description
of the hierarchy within a text/plain entity in the checkgroups
message.
(That possibility could be added in xx years when a successor
to USEFOR is written...)

--

-- 
Julien ÉLIE

« Travailler dur n'a jamais tué personne,
  mais pourquoi prendre le risque ? » (Edgar Bergen)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Russ Allbery | 5 Jun 2009 20:30
Picon
Favicon
Gravatar

Re: multipart/mixed with checkgroups


Julien ÉLIE <julien <at> trigofacile.com> writes:

> Wouldn't it be useful to declare that multipart/mixed SHOULD NOT be
> used with checkgroups but that an implementation SHOULD process
> checkgroups control articles as MIME messages and search for
> an application/news-checkgroups entity?

Eh.  I'm not sure that human-readable bits in control messages is really
that important to support... but I guess it would be occasionally
useful.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply | 4 comments |
headers
rra | 8 Jun 2009 06:12
Picon
Favicon
Gravatar

Commit in docs/usefor (usepro.xml)


    Date: Sunday, June 7, 2009  <at>  21:12:25
  Author: eagle
Revision: 5949

Further updates to the message/news and application/news-transmission
IANA registration templates to match what IANA currently has in their
registration database and, for message/news, the original registration
from Henry Spencer.

Change the security considerations for application/news-transmission to
use the superior wording from Henry Spencer's message/news registration.

Modified:
  docs/usefor/usepro.xml

Modified: docs/usefor/usepro.xml
===================================================================
--- docs/usefor/usepro.xml	2009-06-08 01:48:50 UTC (rev 5948)
+++ docs/usefor/usepro.xml	2009-06-08 04:12:25 UTC (rev 5949)
 <at>  <at>  -1498,12 +1498,14  <at>  <at> 
       registered with IANA as provided for in <xref target="RFC4288"
       />.</t>

-      <t>The media type message/news, as previously registered with
-      IANA, is hereby declared obsolete.  It was never widely
-      implemented, and its default treatment as application/octet-stream
-      by agents that did not recognize it was counter-productive.  The
-      media type message/rfc822 (defined in Section 5.2.1 of
-      <xref target="RFC2046" />) SHOULD be used in its place.</t>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald Alvestrand | 8 Jun 2009 15:54
Picon

Re: multipart/mixed with checkgroups


Russ Allbery wrote:
> Julien ÉLIE <julien <at> trigofacile.com> writes:
>
>   
>> Wouldn't it be useful to declare that multipart/mixed SHOULD NOT be
>> used with checkgroups but that an implementation SHOULD process
>> checkgroups control articles as MIME messages and search for
>> an application/news-checkgroups entity?
>>     
>
> Eh.  I'm not sure that human-readable bits in control messages is really
> that important to support... but I guess it would be occasionally
> useful.
>
>   
Is existing deployed software compatible with such a SHOULD?
If not, I'd say "not worth a change at this time".

                 Harald
Permalink | Reply | 3 comments |

Gmane