headers
Russ Allbery | 2 Feb 2009 02:43
Picon
Favicon
Gravatar

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


"Charles Lindsey" <chl <at> clerew.man.ac.uk> writes:
> Harald Alvestrand <harald <at> alvestrand.no> 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
(Continue reading)

Permalink | Reply | 14 comments |
headers
Russ Allbery | 2 Feb 2009 02:57
Picon
Favicon
Gravatar

Re: [1586] Multiple POSTED in Path: header


"Charles Lindsey" <chl <at> clerew.man.ac.uk> writes:

> 3.4.1 of the present draft contains:
>
> A proto-article has the same format as a normal article except that the
> Injection-Info and Xref header fields MUST NOT be present; the Path
> header field SHOULD NOT contain a "POSTED" <diag-keyword>; and any of
> the following mandatory header fields MAY be omitted:  Message-ID, Date,
> and Path. In all other respects, a proto-article MUST be a valid Netnews
> article. In particular, the header fields which may be omitted MUST NOT
> be present with invalid content.
>
> That "SHOULD NOT" was formerly "MUST NOT", so it is an improvement.
>
> But I propose changing it to:
>
> .. the Path header field MAY contain a "POSTED" <diag-keyword>; ...

Since that is equivalent to saying nothing about the POSTED
<diag-keyword>, were we to decide on this change, I think I would omit the
sentence entirely and just add the note (with corresponding minor wording
changes).  Or even better, move the NOTE to a subsection of 3.2 that
explains the meaning of a POSTED keyword and the circumstances under which
a Path header could be constructed containing several of them.

> and adding a NOTE such as the following:
>
>    NOTE: Whereas the presence of two "POSTED" <diag-keyword>s will often
>    indicate a malicious attempt to disguise the true origin of an article,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Thorfinn | 2 Feb 2009 08:09
Picon
Favicon

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


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.

On 2 Feb 2009, at 12:43, Russ Allbery wrote:

>
> "Charles Lindsey" <chl <at> clerew.man.ac.uk> writes:
>> Harald Alvestrand <harald <at> alvestrand.no> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 2 Feb 2009 13:11
Picon
Picon

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


In <87skmxbol7.fsf_-_ <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>There are four issues in this ticket.

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

>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.

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.
(Continue reading)

Permalink | Reply | 9 comments |
headers
Russ Allbery | 2 Feb 2009 18:14
Picon
Favicon
Gravatar

Re: ISSUE 1583 status


"Charles Lindsey" <chl <at> clerew.man.ac.uk> writes:
> Russ Allbery <rra <at> stanford.edu> 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.

> 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.

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.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Charles Lindsey | 2 Feb 2009 13:25
Picon
Picon

Re: [1586] Multiple POSTED in Path: header


In <87ocxlbnxy.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>"Charles Lindsey" <chl <at> clerew.man.ac.uk> writes:

>> 3.4.1 of the present draft contains:
>>
>> A proto-article has the same format as a normal article except that the
>> Injection-Info and Xref header fields MUST NOT be present; the Path
>> header field SHOULD NOT contain a "POSTED" <diag-keyword>; and any of
>> the following mandatory header fields MAY be omitted:  Message-ID, Date,
>> and Path. In all other respects, a proto-article MUST be a valid Netnews
>> article. In particular, the header fields which may be omitted MUST NOT
>> be present with invalid content.
>>
>> That "SHOULD NOT" was formerly "MUST NOT", so it is an improvement.
>>
>> But I propose changing it to:
>>
>> .. the Path header field MAY contain a "POSTED" <diag-keyword>; ...

>Since that is equivalent to saying nothing about the POSTED
><diag-keyword>, were we to decide on this change, I think I would omit the
>sentence entirely and just add the note (with corresponding minor wording
>changes).  Or even better, move the NOTE to a subsection of 3.2 that
>explains the meaning of a POSTED keyword and the circumstances under which
>a Path header could be constructed containing several of them.

Sure.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russ Allbery | 3 Feb 2009 03:46
Picon
Favicon
Gravatar

Re: [1586] Multiple POSTED in Path: header


"Charles Lindsey" <chl <at> clerew.man.ac.uk> writes:
> Russ Allbery <rra <at> stanford.edu> writes:

>> Since multiple injection is the only means by which multiple POSTED
>> <diag-keywords> can arise with their intended meaning and purpose, it
>> seems pointless to relax the requirement too far in one area and not in
>> the other.

> Agreed. I think that MUST is a bit too strong as regards the Path
> header.  Indeed, it violates 2119 insofar as the protocol does not
> actually break if is it not done - same for Xref for that matter, so it
> is more a matter of what constitutes Good Practice.

If you include Xref in an NNTP POST to an INN server, the article will be
rejected.  That's why I made it a MUST; the protocol does actually break
in practice if you don't strip Xref.  (Whether it *should* is a separate
question, of course, but there's a huge installed base that behaves that
way.)

I agree that current servers do not reject posts that contain a POSTED
<diag-keyword>.

>> I think our options here are:
>
>> 1. Treat the Path header as special and permit (or even encourage)
>>    retaining it while not permitting retention of the other trace headers,
>>    on the grounds that it has an intrinsic ordering and therefore isn't as
>>    prone to confusion as having multiple trace headers that aren't
>>    ordered.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Harald Alvestrand | 3 Feb 2009 13:21
Picon

Re: ISSUE 1583 status


Russ Allbery wrote:
> 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)
>  <at>  <at>  -1953,12 +1953,14  <at>  <at> 
>  
>            <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
>
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Harald Alvestrand | 3 Feb 2009 13:27
Picon

Re: [1586] Multiple POSTED in Path: header


Charles Lindsey wrote:
> 3.4.1 of the present draft contains:
>
> A proto-article has the same format as a normal article except that
> the Injection-Info and Xref header fields MUST NOT be present; the
> Path header field SHOULD NOT contain a "POSTED" <diag-keyword>; and
> any of the following mandatory header fields MAY be omitted:
> Message-ID, Date, and Path. In all other respects, a proto-article
> MUST be a valid Netnews article. In particular, the header fields
> which may be omitted MUST NOT be present with invalid content.
>
> That "SHOULD NOT" was formerly "MUST NOT", so it is an improvement.
>
> But I propose changing it to:
>
> .. the Path header field MAY contain a "POSTED" <diag-keyword>; ...
>
> and adding a NOTE such as the following:
>
>    NOTE: Whereas the presence of two "POSTED" <diag-keyword>s will often
>    indicate a malicious attempt to disguise the true origin of an article,
>    it could also arise following some ususual gatewaying or injecting
>    scenario (taking advantage of the "MAY contain" above), in which case
>    it could be useful for detecting unintended loops or mismanaged
>    gateways. The whole intent of these <path-diagnostic)s is to assist
>    humans in assessing unusual situations, and it would be unwise for
>    subsequent agents automatically to assume one possibility or the other.
>
> Essentially, I am arguing for not throwing away any information which might
(Continue reading)

Permalink | Reply | 1 comment |
headers
Russ Allbery | 4 Feb 2009 03:45
Picon
Favicon
Gravatar

Re: ISSUE 1583 status


Harald Alvestrand <harald <at> alvestrand.no> writes:
> Russ Allbery wrote:

>> 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)
>>  <at>  <at>  -1953,12 +1953,14  <at>  <at> 
>>             <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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane