Subject: ISSUE 1583 status (was: Re: January: open issues on USEPRO)

From: Russ Allbery <[email-masked]>
Date: Sun, 01 Feb 2009 17:43:32 -0800

"Charles Lindsey" <[email-masked]> writes:
> Harald Alvestrand <[email-masked]> writes:

>> 1583 USEPRO LC 5.2.3: Checkgroups control messages
>>    Open. There may be multiple issues here.
>>    No discussion with "1583" in the subject.

> I think we agreed that the present checkgroups message has a problem. The
> draft introduces a new feature which addresses that problem, which will
> work fine if checkgroups issuers use it, and it checkgroups receivers
> recognise it.

> But if it isn't used or recognised, then the original problem will
> remain, and there is nothing much we can do about it. Therefore I think
> no action is needed - the present wording is the best that can be done.

There are four issues in this ticket.

The first issue is that there's no method in the checkgroups syntax to
delegate control over a newsgroup whose name matches the subhierarchy.  I
think we agreed that, yes, this is the case, and there's nothing we can
really do about it at this stage and while still remaining
backwards-compatible.

The second issue was about whether there should be a maximum size of the
serial number.  I believe we decided that since you can compare serial
numbers as strings, there wasn't a need to set a limit.

The third issue is about what to do when a serial number is specified for
a hierarchy and then a subsequent control message arrives without a serial
number.  The current document is silent on what to do in this situation.
I think it should state what should be done.  My sense of the previous
discussion was that most people felt that such a checkgroups should be
ignored, meaning that once an authorized control message sender starts
issuing checkgroups with serial numbers, subsequent checkgroups for that
hierarchy must always use serial numbers, which must always be larger than
the previous serial number.  I'm a little worried about this provision,
since after long periods of time and a change of hierarchy administration
it can be potentially difficult to uncover the previous serial number.
But I don't see a good alternative that preserves the serial number
semantics.

The fourth issue is whether there should be a mechanism to reset the
serial number.  I think we decided that we weren't going to specify one.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Thorfinn <[email-masked]>
Date: Mon, 2 Feb 2009 18:09:36 +1100

Discussion mostly occurred in late September 2008, under the subject  
line:
ISSUE: Checkgroups control messages

I can't remember whether we had issue numbers at that point, but for  
some reason the original subject line didn't, and nobody fixed it.

I had something to say back then regarding sub-issues 2 and 4 below,  
and had nothing to say at that time about 1 and 3.

> really do about it at this stage and while still remaining

I think someone mentioned something about issuing the delegation in  
the parent checkgroups, but I don't recall the details.

> numbers as strings, there wasn't a need to set a limit.

Yes.  Specifically, if you skip any leading zeros, then compare string  
length, then asciibetically compare if strings are the same length,  
you have an ordered integer comparison method, with no need to  
actually use an integer representation at any point.

Given the infrequency of checkgroups, the relative inefficiency of  
this comparison vs integer comparisons is a total non issue.

> But I don't see a good alternative that preserves the serial number

I don't see any way to do that.  I think it's a reasonable assumption  
that if you can't find a serial number anywhere, including by posting  
in newsgroups and asking newsmasters for what their latest one is,  
then it has probably become irrelevant.  After all, if nobody at all  
knows what their latest checkgroups serial number is, then they can't  
be able to compare with it.

This seems like an "unlikely to be a problem" situation to me.  I  
think we should explicitly say that once you have gone to serial  
numbers, there is no way back to having no serial numbers.

> serial number.  I think we decided that we weren't going to specify  

Yes, I believe we should not specify one - there is no good way to  
specify a reset, and combined with the ability to simply continue  
incrementing into integer infinity, there is no need for a reset.

The closest thing was my suggestion that we could use the DNS serial  
number mechanism of sequence space arithmetic (i.e. a wrap-around -  
see DNS RFCs or the original discussion in september for details if  
needed), but I believe that that is more problematic than simply  
allowing incrementing into infinity.

Ook,

  Thorf

-- 
<a href="http://tertius.net.au/~thorfinn/">[email-masked]</a>
The world is coming to an end.  Please log off.  -- BSD fortune file

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 2 Feb 2009 12:11:38 GMT

>There are four issues in this ticket.

But it seems that the third is the only one where we might take any
further action.

>But I don't see a good alternative that preserves the serial number

I am slightly worried about being too specific here, for the reason you
mention. Perhaps some wording to the effect that newsadmins should think
carefully before accepting such a checkgroups (and in any case, blind
automatic acceptance of checkgroups has never been a recommended
practice). I wouldn't want to say anything stronger than that, and would
be happy to leave it as it stands.

So by all means suggest a wording if you like, or else let it be.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131            Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

---

From: Russ Allbery <[email-masked]>
Date: Mon, 02 Feb 2009 09:14:30 -0800

"Charles Lindsey" <[email-masked]> writes:
> Russ Allbery <[email-masked]> writes:

>> The third issue is about what to do when a serial number is specified
>> for a hierarchy and then a subsequent control message arrives without a
>> serial number.  The current document is silent on what to do in this
>> situation.  I think it should state what should be done.  My sense of
>> the previous discussion was that most people felt that such a
>> checkgroups should be ignored, meaning that once an authorized control
>> message sender starts issuing checkgroups with serial numbers,
>> subsequent checkgroups for that hierarchy must always use serial
>> numbers, which must always be larger than the previous serial number.
>> I'm a little worried about this provision, since after long periods of
>> time and a change of hierarchy administration it can be potentially
>> difficult to uncover the previous serial number.  But I don't see a
>> good alternative that preserves the serial number semantics.

> So by all means suggest a wording if you like, or else let it be.

Here's proposed wording, which uses SHOULD rather than MUST for the
honoring side to leave wiggle room for things like a lost serial number.

--- usepro.xml  (revision 5620)
+++ usepro.xml  (working copy)
@@ -1953,12 +1953,14 @@
 
           <t>The &lt;chksernr> argument may be any positive integer.  If
           present, it MUST increase with every change to the newsgroup
-          list and MUST NOT ever decrease.  If provided, news servers
-          SHOULD remember the &lt;chksernr> value of the previous
-          checkgroups control message honored for a particular hierarchy
-          or sub-hierarchy and decline to honor any subsequent checkgroups
-          control message for the same hierarchy or sub-hierarchy with a
-          smaller &lt;chksernr> value.</t>
+          list, MUST NOT ever decrease, and MUST be included in all
+          subsequent checkgroups control messages with the same scope.
+          If provided, news servers SHOULD remember the &lt;chksernr>
+          value of the previous checkgroups control message honored for a
+          particular hierarchy or sub-hierarchy and decline to honor any
+          subsequent checkgroups control message for the same hierarchy
+          or sub-hierarchy with a smaller &lt;chksernr> value or with no
+          &lt;chksernr> value.</t>
 
           <figure>
             <preamble>For example, the following Control header

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Feb 2009 13:21:18 +0100

> +++ usepro.xml  (working copy)
I'm not very worried about this issue, but this seems fine with me.
(couldn't find the change to the text surrounding the SHOULD, but I 
think the SHOULD leaves wiggle room enough for the case where weird 
stuff has happened.)

                    Harald

---

From: Russ Allbery <[email-masked]>
Date: Tue, 03 Feb 2009 18:45:57 -0800

> think the SHOULD leaves wiggle room enough for the case where weird

Does anyone have any objections?  If not, I'll go ahead and commit this.

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 4 Feb 2009 11:02:56 GMT

>+          &lt;chksernr> value.</t>

A touch too strong for my liking. Perhaps "... and report for human
evaluation any subsequent checkgroups control message for the same
hierarchy or sub-hierarchy with a smaller &lt;chksernr> value or with no
&lt;chksernr> value.".

But even that seems to suggest that valid chechgroups should be accepted
on "auto-pilot", which is probably not a good idea.

But I am not pressing this too strongly if others are happy.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 13 Feb 2009 17:45:02 +0100

> But I am not pressing this too strongly if others are happy.
So far, Russ and I are happy, and the rest of the list are silent, so 
you're a minority. Let's finish this one.

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 13 Feb 2009 18:31:38 +0100

Hi Harald,

> So far, Russ and I are happy, and the rest of the list are silent, so you're a minority. Let's finish this one.

I also agree with that change (always including serial numbers once a
checkgroups has used them).
Shouldn't we add that serials should be compared as a string and not
as a number owing to their not being limited in size?  A note to future
implementors would be useful.
I also wonder whether we should not change (or add?) the current example

-    Control: checkgroups de !de.alt #248
+    Control: checkgroups de !de.alt #2009021301

to show a preferred way to use serial numbers.  It would be convenient
for checkgroups senders not not worry much about the previous number used.

-- 
Julien ÉLIE

« J'aime le travail, je passerais des heures à le regarder. »

---

From: Russ Allbery <[email-masked]>
Date: Fri, 13 Feb 2009 14:43:52 -0800

Julien ÉLIE <[email-masked]> writes:

> Shouldn't we add that serials should be compared as a string and not as
> a number owing to their not being limited in size?  A note to future
> implementors would be useful.  I also wonder whether we should not
> change (or add?) the current example
>

How does this patch look to everyone?

Index: usepro.xml
===================================================================
--- usepro.xml	(revision 5725)
+++ usepro.xml	(working copy)
@@ -1962,19 +1962,28 @@
           or sub-hierarchy with a smaller &lt;chksernr> value or with no
           &lt;chksernr> value.</t>
 
+          <t>There is no upper limit on the length of &lt;chksernr>
+          other than the limitation on the length of header fields.
+          Implementations may therefore want to do comparisons by
+          zero-padding the shorter of two &lt;chksernr> values on the
+          left and then doing a string comparison rather than assuming
+          &lt;chksernr> can be manipulated as a number.</t>
+
           <figure>
             <preamble>For example, the following Control header
             field</preamble>
 
             <artwork>
             </artwork>
 
             <postamble>indicates the body of the message will list every
             newsgroup in the de.* hierarchy, excepting the de.alt.*
             sub-hierarchy, and should not be honored if a checkgroups
-            control message with a serial number greater than 248 was
-            previously honored.</postamble>
+            control message with a serial number greater than 2009021301
+            was previously honored.  The serial number in this example
+            was formed from the date in YYYYMMDD format followed by a
+            two-digit sequence number within that date.</postamble>
           </figure>
 
           <t>The body of the message is an entity of type

---

From: Julien ÉLIE <[email-masked]>
Date: Sat, 14 Feb 2009 10:47:59 +0100

Hi Russ,

> How does this patch look to everyone?

It sounds great to me.  Clear and precise.  Thanks!

-- 
Julien ÉLIE

« La vraie paresse, c'est de se lever à 6 heures du matin pour
  avoir plus longtemps à ne rien faire. » (Tristan Bernard)

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 16 Feb 2009 10:57:20 GMT

>you're a minority. Let's finish this one.

As I said, I do not press this issue strongly, so let it be. I see Ruus
has now comitted it to his working text.