[NNTP] [2508] LIST capability handling

Ken Murchison ken at oceana.com
Thu Dec 2 07:12:08 PST 2004


Clive D.W. Feather wrote:

> Russ Allbery said:
> 
>>Er, the client should look at the specification for that particular LIST
>>command to figure out whether it takes a wildmat.  If we're not requiring
>>a specification here in some form, I think we may be going down the wrong
>>road.  If the client doesn't have access to a specification, it's going to
>>have a lot more problems than just not knowing whether to include a
>>wildmat, like having any clue whatsoever what the output is supposed to
>>mean.
> 
> 
> True. Ish.
> 
> Given that (currently - I know there's another thread) the only valid
> argument to an arbitrary LIST keyword command is a wildmat, this struck me
> as an "almost no pain, some gain" sort of thing.

Why does it have to be defined that way?  I discussed this in another 
post, but why can't LIST be defined as:

LIST [ keyword *(WSP argument) ]


and each variant describes in detail what the keyword and argument(s) 
are?  Maybe I should extract my text and start a new thread discussing LIST?


> Would anyone object violently to wording saying that future versions of
> this specification, or extensions, may put non-alphanumeric suffixes on
> the keywords in the LIST capability line? The purpose would be to give room
> for future changes or improvements without having to go through a "client
> says it's willing to receive this" loop. Note:
> * Servers need to do nothing to conform to this.
> * Clients need only make sure they won't barf if such a suffix appears;
>   they can ignore it.

I'm completely clueless as to what problem this is trying to solve or 
feature its trying to add.  Can you elaborate?

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



More information about the ietf-nntp mailing list