[ietf-nntp] I-D ACTION:draft-ietf-nntpext-authinfo-00.txt
Clive D.W. Feather
clive at demon.net
Thu May 20 08:02:21 PDT 2004
Ken Murchison said:
>> This is breaking NNTP-BASE concepts. *ANY* response in NNTP can be followed
>> by arbitrary junk and *ALL* responses must have consistent syntax so that
>> they can be parsed easily. I see no grounds to break this. Consider:
>>
>> [C] AUTHINFO SASL DIGEST-MD5
>> [S] 383 This is a piece of trailing junk.
>
> Why can't an extension dictate the syntax and content of a response code
> specific to itself?
Because we wrote:
to simplify interpretation by the client the number and type of such
arguments is fixed for each response code, as is whether or not the
code introduces a multi-line response. Any extension MUST follow this
principle as well,
[We acknowledge that LISTGROUP/211 breaks this, but it's the only one.]
The whole point of this wording was to allow clients to have a standard
response-parsing module. Even if:
> Most, if not all, AUTHINFO SASL implementations are
> probably going to have special code to handle the SASL exchanges
> anyways,
that doesn't mean that code won't call the standard "get and parse a
response" module.
(1) To change this requires changing the base document. I, for one, will
oppose any such change.
(2) It's equally easy for the server to return "383 *" as "383 ", and it's
equally easy for the client to go:
switch (arglist [1][0])
{
case '*': /* no response code ... */ break;
case '=': /* empty response code ... */ break;
default: /* base64 response code ... */ break;
}
as:
if (n_args == 0)
/* no response code ... */ ... ;
switch (arglist [1][0])
{
case '=': /* empty response code ... */ break;
default: /* base64 response code ... */ break;
}
Indeed, if a standard parsing module is used it may well be easier.
--
Clive D.W. Feather | Work: <clive at demon.net> | Tel: +44 20 8495 6138
Internet Expert | Home: <clive at davros.org> | Fax: +44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc | |
More information about the ietf-nntp
mailing list