[ietf-nntp] OVER message-id

[Ken Murchison]

Clive D.W. Feather wrote:
> Russ Allbery said:
> 
>>>>At some point we put "OVER message-id" back into the protocol.  Andrew
>>>>from Supernews is objecting to this, saying that it's impractical in
>>>>"every major server design".
> 
> 
>>Anyway, given that OVER on message IDs is an innovation of this working
>>group that we added based on a few people saying it would be useful rather
>>than based on existing practice, and given the stage that we're at with
>>this draft, I think we should just drop OVER on message IDs again and not
>>spend a bunch of time on this.  Servers can easily add it as an extension
>>since it doesn't conflict with the base command grammar, and if it turns
>>out to be a common extension, we can revisit it in a future standard
>>revision.
> 
> 
> Can I suggest that we make it optional instead? That way we don't lose the
> work done on it and, far more importantly, we ensure that people handle the
> subtleties (e.g. returning a message number of 0) in a consistent manner.

Again, are there any client authors out there?  Does anyone think that 
this is useful?  If not, then I agree with Russ that this can be 
removed.  Otherwise, making it optional would be easy to advertise by 
tweaking the OVER capability, e.g.

OVER+       or
OVER +MSGID


> How do we handle the HDR cases that Andrew mentioned?
> 
>     HDR Xref <message-id>
>     HDR :lines <message-id>
> 
> If we're going to live with it then I suggest:
> 
> (1) We need text saying that you can get 503 with message-id even if the
> header is available with article number.
> (2) LIST HEADERS ought to distinguish these cases (e.g. by putting "-<>"
> or "NOMSGID" in the output for those headers:
> 
>     [C] LIST HEADERS
>     [S] 215 headers and metadata items supported:
>     [S] Date
>     [S] Distribution
>     [S] From
>     [S] Message-ID
>     [S] References
>     [S] Subject
>     [S] -<> Xref
>     [S] -<> :bytes
>     [S] -<> :lines
>     [S] .

I think this is getting too ugly.  I think allowing msgid for HDR should 
be all or nothing, not per header per access method.  Either the server 
supports HDR msgid for all of the same headers that it can access by 
msgno, or it doesn't advertise the ability to fetch by msgid.  I'd 
suggest something like I proposed above for OVER as the capability, e.g.:

HDR[+] [ALL]    or
HDR [+MSGID] [ALL]

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp