[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