Re: Niggles in usepro-draft-11

["Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>]

In <87prmxrms3.fsf@xxxxxxxxxxxxxxxxxxxxx> Russ Allbery <rra@xxxxxxxxxxxx> writes:

>"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx> writes:

OK, you seem to have covered most of my suggestions, and I have created
Issues for the two that need discussion, as you suggested.

Here are a few remaining niggles.

>> 3.3.  Article History and Duplicate Suppression
>>
>>    o  ............  If this
>>       interval is shorter than the time it takes for an article to
>>       propagate through the network, the agent might reject an article
>>       it had not yet seen, so it ought not be aggressively short. .....
>>                                           ^
>>                                           to

>It's an unusual formulation in general, but I believe the current
>formulation is more grammatically correct.  The subject of the dependent
>clause is "it" and the verb is "be".  If "be" is converted to an
>infinitive, the dependent clause no longer has a verb.

No, the verb in that dependent clause is "ought".

Consider the sentence "You ought to know better." Surely that is
gramatically correct, but it needs the infinitive "to know" to make it
work.

It would be similar in French: "Il vous faut savoir mieux."

>> 3.4.2.  Multiple Injection of Articles

>I now have the following, which makes the handling of Path consistent with
>the current definition of a proto-article.  This is only provisional until
>we resolve handling of the POSTED <diag-keyword> in Path as discussed
>above.

>    <t>In some cases, offering the same proto-article to all
>    injecting agents may not be possible (such as when gatewaying,
>    after injection, articles found on one Netnews network to
>    another, supposedly unconnected one).  In this case, the posting
                                    ^
                                    ,
>    agent MUST remove any Xref header field and rename or remove any
>    Injection-Info, Path, and other trace header field before
>    passing it to another injecting agent.  (This converts the
                                          ^^^^^^^^
                                           (this
>    article back into a proto-article.)  It MUST retain unmodified
>    the Message-ID, Date, and Injection-Date header fields.  It MUST
>    NOT add an Injection-Date header field if it is missing from the
>    existing article.

>> 5.4.  The Supersedes Header Field
>>
>>    The presence of a Supersedes header field in an article requests that
>>    the message identifier given in that header field be withdrawn in
>>    exactly the same manner as if it were the target of a cancel control
>>    message.  Accordingly, news servers SHOULD use the same
>>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>    authentication and authorization checks for deciding whether to honor
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>    a Supersedes header field as they use for cancel control messages.
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>    If the Supersedes header field is honored, the news server SHOULD
>>    take the same actions as it would take when honoring a cancel control
>>    message for the given target article.
>>
>> The bit I have marked with ^^^^^^^^ is all fine and dandy, except that
>> the preceding section 5.3 on Cancel Messages make no mention of
>> "authentication and authorization".

>It's covered by section 5.1.

>> However, what is currently said in our section 5.1 is fine (so far as it
>> goes) for Group Control Messages, but has nothing to say of relevance to
>> Cancels and Supersedes.

>How so?  I think this pretty much covers it:

>   Agents acting on control messages SHOULD take steps to authenticate
>   control messages before acting on them, as determined by local
>   authorization policy.  Whether this is done via the use of an
>   unstandardized authentication protocol, by comparison with
>   information obtained through another protocol, by human review, or by
>   some other means is left unspecified by this document.  Further
>   extensions or revisions of this protocol are expected to standardize
>   a digital signature mechanism.

>There isn't anything specific to group control messages there.  Those are,
>stated generally, exactly the same provisions as should apply to cancel
>messages and Supersedes.

Yes, but we make a suggestion (explicitly 'pgpverify' now) in the case of
control messages, but remain devoid of suggestions for cancels.

Perhaps the following alternative wording would convey the sense better:

>>    message.  Accordingly, news servers SHOULD use the same
>>                                               ^^^^^^^^^^^^
                                                 apply whatever
>>    authentication and authorization checks for deciding whether to honor
>>                                           ^
                                      they already apply
>>    a Supersedes header field as they use for cancel control messages.
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                 in the case of

which has the advantage of being shorter, and gives no implication that
such checks are normal for cancel messages (which, sadly, they are not).

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