[NNTP] Extension docs snapshots

Ken Murchison ken at oceana.com
Wed Nov 17 08:10:36 PST 2004


Clive D.W. Feather wrote:

> Ken Murchison said:
> 
>>>authinfo, section 3.1, last para,
>>>  s/and CRLF as the/and CRLF, both exclusive, as the/
>>
>>Is "both exclusive" intended to pair up USER and PASS with username and 
>>password respectively?
> 
> 
> No.
> 
> <Quietly sobs to self>
> 
> Consider the following command, using . to represent space:
> 
>     USER..fred.flintstone.
> 
> Is the username:
> 
>     .fred.flintstone.

The is the intended username, which I think you understand, but as you 
point out isn't explicit with the current text.


>     ..fred.flintstone.
>     .fred.flintstone.[CRLF]
> or
>     ..fred.flintstone.[CRLF]
> ?
> 
> The intent of my wording is to say that the space after USER/PASS is not
> part of the password, and nor is the CRLF.

Yup.  I thought about this right after I sent the previous message.


> Okay, try this:
> 
>     To solve this ambiguity,
>     such implementations typically treat everything after the first
>     white space character following "USER"/"PASS", up to but excluding
>     the CRLF, as the username/password.

Works for me.


>>>streaming, section 2.3.1, why is MODE STREAM "MUST NOT be pipelined"?
> 
> 
>>Don't know.  Someone more familiar with streaming (Andrew?) needs to 
>>chime in here.  I don't recall when this came into the document.  It 
>>seems to me that any argument that can be made for MODE READER can be 
>>made for MODE STREAM and vice versa.
> 
> 
> The argument for MODE READER is that it invokes an entire new application.
> But, as I understand it, MODE STREAM merely confirms that the other two
> commands in the extension are implemented.

That's my understanding, but do we know for sure that some 
implementations don't fork a new app (or convolute itself in some other 
way) for MODE STREAM?

Even if the client is just probing the server to see if it can do 
CHECK/TAKETHIS, isn't the friendly thing to wait until the server says 
"yea" or "nea" before trying the command?  Obviously the server can just 
return 501/503 (which ever is appropriate) to CHECK if pipelined but 
unsupported.  I don't care either way.  Does anyone else have a strong 
opinion?

As an aside, I notice that LIST EXTENSIONS is allowed to be pipelined 
(its not prohibited in -25).  Shouldn't we encourage friendly behavior 
and not allow it to be pipelined (at least not with optional 
commands/extensions)?  Either way, MODE STREAM should probably be 
consistent with LIST EXTENSIONS since its essentially a capability 
discovery command.


>>>streaming, section 2.3.2, para 1: make it clear that a 501 is allowed if an
>>>argument is given, and that the server state must not be affected by this
>>>command. So something like:
>>>   ... to the MODE STREAM command (or 501 if an argument is given).
>>
>>Is explicitly mentioning 501 really necessary?  If so, why don't we 
>>mention it for NEXT?
 >
> If you look at QUIT, I say:
> 
>     The server MUST NOT generate any response code to the QUIT command
>     other than 205 or, if any arguments are provided, 501. 
> 
> to indicate that other generic responses are forbidden. Could you bring
> yourself to keep to that formulation?

Sure.  Not a problem.


>>>* I've seen *NO* feedback on 25-pre3, which rewrites the MODE READER issue
>>>in terms of "transit" and "reader" connections.
> 
> [...]
> 
>>I'm waiting for all of the dust to settle on the above before I make any 
>>changes.
> 
> 
> Sure. As I said, I've had *NO* feedback yet, which slightly bothers me.

FWIW, I'm OK with the 25-pre3 text for the most part.



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