[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