headers
Russ Allbery | 5 Jul 2009 00:42
Picon
Favicon
Gravatar

Proposed changes for <chkscope>


I think I received no feedback for this proposed diff other than
agreement from Julien.  Given that we're in AUTH48, in the absence of
more consensus on the list that this is worth pushing at this phase, I'm
not going to try to ask the RFC Editor to include it.

So if you want me to push for this change, please speak up now.

Index: usepro.xml
===================================================================
--- usepro.xml  (revision 5949)
+++ usepro.xml  (working copy)
 <at>  <at>  -2022,14 +2022,24  <at>  <at> 
           the valid groups in all hierarchies or sub-hierarchies with a
           prefix listed in the &lt;chkscope> argument, excluding any
           sub-hierarchy where the &lt;chkscope> argument is prefixed by
-          "!".  If no &lt;chkscope> argument is given, it applies to all
+          "!".  For complex cases with multiple &lt;chkscope> arguments,
+          start from an empty list of groups, include all groups in the
+          checkgroups control message matching &lt;chkscope> arguments
+          without a "!" prefix, and then exclude all groups matching
+          &lt;chkscope> arguments with a "!" prefix.  Follow this method
+          regardless of the order of the &lt;chkscope> arguments in the
+          Control header field.</t>
+
+          <t>If no &lt;chkscope> argument is given, it applies to all
           hierarchies for which group statements appear in the body of the
-          message.  Since much existing software does not honor the
-          &lt;chkscope> argument, the body of the checkgroups control
-          message MUST NOT contain group statements for newsgroups outside
(Continue reading)

Permalink | Reply | 2 comments |
headers
Julien ÉLIE | 5 Jul 2009 11:19
Favicon

Re: Proposed changes for <chkscope>


Hi all,

> I think I received no feedback for this proposed diff other than
> agreement from Julien.

Harald was also in favour of a diff (but it was before you actually
wrote it):
    http://www.imc.org/ietf-usefor/mail-archive/msg04638.html

    "It seems to me that since we're incompatible with something
     people will also know about (wildmat), flagging the
     incompatibility is important."

> Given that we're in AUTH48, in the absence of
> more consensus on the list that this is worth pushing at this phase, I'm
> not going to try to ask the RFC Editor to include it.

Please note that if this diff is not in USEPRO, it will lead to various
incompatible implementations of checkgroups processing, like this one
we have already seen on news.software.nntp:

"When one expression describes a subset of another expression in an
opposite manner (inclusion vs. exclusion), an order of processing is
necessary to resolve the conflicting directives.

Given:  a,  a.b,  a.b.c,  a.b.c.d

In the order "a !a.b a.b.c !a.b.c.d", natural left-to-right processing is
the same as superset-subset order, so what results is that we include "all
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien ÉLIE | 5 Jul 2009 11:26
Favicon

Re: USEAGE referenced for Archive


Hi Charles,

> The following text was planned for useage-02. Maybe I will even get around
> to useage-02 :-).

OK, thanks for the pointer.

I transmitted the information to Xavier Roche and for his NoCeM notices
sent to news.lists.filters (and soon to fr.usenet.abus.nocem -- that's
for it we needed the information to mention the headers in the charter),
he now uses both of them:

    X-No-Archive: Yes
    Archive: No

It will maybe take a long time before switching to only the Archive: header...

--

-- 
Julien ÉLIE

« -- Par Thor !
  -- Par Odin !
  -- Par exemple ! » (Astérix)
Permalink | Reply | 0 comments |
headers
Harald Tveit Alvestrand | 12 Jul 2009 23:15
Picon

Re: Proposed changes for <chkscope>


Russ Allbery skrev:
> I think I received no feedback for this proposed diff other than
> agreement from Julien.  Given that we're in AUTH48, in the absence of
> more consensus on the list that this is worth pushing at this phase, I'm
> not going to try to ask the RFC Editor to include it.
>
> So if you want me to push for this change, please speak up now.
>   
I'd like to see this change.
> Index: usepro.xml
> ===================================================================
> --- usepro.xml  (revision 5949)
> +++ usepro.xml  (working copy)
>  <at>  <at>  -2022,14 +2022,24  <at>  <at> 
>            the valid groups in all hierarchies or sub-hierarchies with a
>            prefix listed in the &lt;chkscope> argument, excluding any
>            sub-hierarchy where the &lt;chkscope> argument is prefixed by
> -          "!".  If no &lt;chkscope> argument is given, it applies to all
> +          "!".  For complex cases with multiple &lt;chkscope> arguments,
> +          start from an empty list of groups, include all groups in the
> +          checkgroups control message matching &lt;chkscope> arguments
> +          without a "!" prefix, and then exclude all groups matching
> +          &lt;chkscope> arguments with a "!" prefix.  Follow this method
> +          regardless of the order of the &lt;chkscope> arguments in the
> +          Control header field.</t>
> +
> +          <t>If no &lt;chkscope> argument is given, it applies to all
>            hierarchies for which group statements appear in the body of the
> -          message.  Since much existing software does not honor the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 22 Jul 2009 15:58
Picon
Picon

Son-of-1036


The RFC Editor is proceeding with the draft I submitted in May. It will be
a Historic RFC as we had asked, but they want a line below that to state
that it is "Superseded by RFC5536 and RFC5537" (that is in addition to the
clear warnings in the Abstract and in the Preface to the effect that the
document is NOT to be considered as a basis for current implementations).
They also asked for a mention that RFC822 is now replaced by 5532.

Is there anything else that might cause confusion and that should be
warned against?

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131            Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      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
Permalink | Reply | 3 comments |
headers
Julien ÉLIE | 22 Jul 2009 19:29
Favicon

Re: Son-of-1036


Hi Charles,

> The RFC Editor is proceeding with the draft I submitted in May. It will be
> a Historic RFC as we had asked, but they want a line below that to state
> that it is "Superseded by RFC5536 and RFC5537" (that is in addition to the
> clear warnings in the Abstract and in the Preface to the effect that the
> document is NOT to be considered as a basis for current implementations).

Does it also imply that RFC 5536 and RFC 5537 will mention that they
update that RFC when dislpayed on <http://tools.ietf.org/html/>?
(just above "Category: Standards Track")

> Is there anything else that might cause confusion and that should be
> warned against?

Shouldn't the date "3 May 2009" be changed to "2 June 1994"?  (and the sentence
"This document is identical to the last distributed version of Son of 1036,
dated 2 June 1994, except for reformatting" rewritten to say it was submitted
on May, 3rd 2009)
That date would highlight more the fact it is an *old* RFC.

It is just a suggestion; maybe it is impossible to change that date.

Thanks for all your work, Charles.

--

-- 
Julien ÉLIE

« Hâte-toi de bien vivre et songe que chaque jour
(Continue reading)

Permalink | Reply | 2 comments |
headers
Charles Lindsey | 23 Jul 2009 12:35
Picon
Picon

Re: Son-of-1036


In <0C8DE6FE57CF4FF9AEF423A2C16AE15B <at> Iulius> =?Windows-1252?Q?Julien_=C9LIE?=
<julien <at> trigofacile.com> writes:

>Hi Charles,

>> The RFC Editor is proceeding with the draft I submitted in May. It will be
>> a Historic RFC as we had asked, but they want a line below that to state
>> that it is "Superseded by RFC5536 and RFC5537" (that is in addition to the
>> clear warnings in the Abstract and in the Preface to the effect that the
>> document is NOT to be considered as a basis for current implementations).

>Does it also imply that RFC 5536 and RFC 5537 will mention that they
>update that RFC when dislpayed on <http://tools.ietf.org/html/>?
>(just above "Category: Standards Track).

No. Both those documents contain non-normative references to s-o-1036, of
course, and hopefully they will refer to it via its republished form. But
I think those documents are already clear to to what they update (1036)
and that s-o-1036 was just a useful stopgap on the way to that goal.

>Shouldn't the date "3 May 2009" be changed to "2 June 1994"?  (and the sentence
>"This document is identical to the last distributed version of Son of 1036,
>dated 2 June 1994, except for reformatting" rewritten to say it was submitted
>on May, 3rd 2009)
>That date would highlight more the fact it is an *old* RFC.

>It is just a suggestion; maybe it is impossible to change that date.

I doubt it would be possible, and would create more confusion than it
(Continue reading)

Permalink | Reply | 1 comment |
headers
Antti-Juhani Kaijanaho | 23 Jul 2009 14:28
Picon

Re: Son-of-1036


On Thu, Jul 23, 2009 at 10:35:35AM +0000, Charles Lindsey wrote:
> >Does it also imply that RFC 5536 and RFC 5537 will mention that they
> >update that RFC when dislpayed on <http://tools.ietf.org/html/>?
> >(just above "Category: Standards Track).
> 
> No. Both those documents contain non-normative references to s-o-1036, of
> course, and hopefully they will refer to it via its republished form. But
> I think those documents are already clear to to what they update (1036)
> and that s-o-1036 was just a useful stopgap on the way to that goal.

It would make the connection (and their relation) explicit in indexes.  It
seems to me to be a useful thing.

--

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 29 Jul 2009 12:05
Picon
Picon

Re: I-D ACTION:draft-spencer-usefor-son-of-1036-01.txt


In <20090728090002.11D523A6D3C <at> core3.amsl.com> Internet-Drafts <at> ietf.org writes:

>--NextPart

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.

>	Title		: "Son of 1036":  News Article Format and Transmission
>	Author(s)	: H. Spencer
>	Filename	: draft-spencer-usefor-son-of-1036-01.txt
>	Pages		: 91
>	Date		: 2009-7-28
>
This just includes a few tweaks requested by the RFC-Editor. Hopefully it
is now ready for final publication.

>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-spencer-usefor-son-of-1036-01.txt

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131            Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clerew.man.ac.uk      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
Permalink | Reply | 4 comments |
headers
Julien ÉLIE | 29 Jul 2009 19:38
Favicon

Re: I-D ACTION:draft-spencer-usefor-son-of-1036-01.txt


Hi Charles,

> This just includes a few tweaks requested by the RFC-Editor. Hopefully it
> is now ready for final publication.

I have just done a diff between the two versions.  Only four or five changes.
Amongst them, a sentence has been rewritten but still needs to be changed.
(", and the presence of unresolved issues.")

   The technical content remains unchanged, including the references to
   the document itself as a Draft rather than an RFC, the presence of
   unresolved issues, The original section numbering has been preserved,
   although the original pagination has not (among other reasons, it did
   not fully follow IETF formatting standards).

The few typos I reported in May weren't fixed in that new version.

Have a nice day,

--

-- 
Julien ÉLIE

« Il y a un proverbe serbe qui dit ceci : « Notre passé est sinistre,
  notre présent est invivable, heureusement que nous n'avons pas d'avenir ! »
  (Philippe Geluck)
Permalink | Reply | 3 comments |

Gmane