headers
Antti-Juhani Kaijanaho | 14 May 2009 22:22
Picon

[NNTP] RFC 4643 user-pass-char question

Hi

RFC 4643 section 3.1 says, in part:

   user-pass-char = B-CHAR

   NOTE: a server implementation MAY parse AUTHINFO USER and AUTHINFO
   PASS specially so as to allow white space to be used within the
   username or password.  Such implementations accept the additional
   syntax (making these two items inconsistent with "token" in Section
   9.8 of [NNTP]):

   user-pass-char =/ SP / TAB

Now, B-CHAR is defined in RFC 3977, section 9.8 as

   B-CHAR     = CTRL / TAB / SP / %x21-FF

It seems to me that the NOTE in 4643 § 3.1, particularly the rule augmenting
user-pass-char is redundant, since SP and TAB are B-CHARs.

My question is, what is this note *intended* to convey?

Draft 9 (June 2005) had P-CHAR instead of B-CHAR.  Draft 10 (August 2005) has
B-CHAR.  The change seems to have been proposed at
http://lists.eyrie.org/pipermail/ietf-nntp/2005-August/005840.html, but its
effect on the NOTE is not discussed.

The question I was trying to resolve by reading the grammar was, is it
permissible (or eve required) for a server to respond with 501 to an AUTHINFO
(Continue reading)

Permalink | Reply | 4 comments |
headers
Russ Allbery | 14 May 2009 22:32
Picon
Favicon
Gravatar

Re: [NNTP] RFC 4643 user-pass-char question

Antti-Juhani Kaijanaho <antti-juhani <at> kaijanaho.fi> writes:

> RFC 4643 section 3.1 says, in part:
>
>    user-pass-char = B-CHAR
>
>    NOTE: a server implementation MAY parse AUTHINFO USER and AUTHINFO
>    PASS specially so as to allow white space to be used within the
>    username or password.  Such implementations accept the additional
>    syntax (making these two items inconsistent with "token" in Section
>    9.8 of [NNTP]):
>
>    user-pass-char =/ SP / TAB
>
> Now, B-CHAR is defined in RFC 3977, section 9.8 as
>
>    B-CHAR     = CTRL / TAB / SP / %x21-FF

Urgh.

> It seems to me that the NOTE in 4643 § 3.1, particularly the rule
> augmenting user-pass-char is redundant, since SP and TAB are B-CHARs.
>
> My question is, what is this note *intended* to convey?

It's intended to convey that usernames and passwords containing spaces
MAY be supported but are not required to be supported, and servers MAY
reject them, if I recall correctly.

> Draft 9 (June 2005) had P-CHAR instead of B-CHAR.  Draft 10 (August
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien ÉLIE | 14 May 2009 23:23
Favicon

Re: [NNTP] RFC 4643 user-pass-char question

Hi Antti-Juhani,

>   NOTE: a server implementation MAY parse AUTHINFO USER and AUTHINFO
>   PASS specially so as to allow white space to be used within the
>   username or password.  Such implementations accept the additional
>   syntax (making these two items inconsistent with "token" in Section
>   9.8 of [NNTP]):
>
>   user-pass-char =/ SP / TAB
>
> The question I was trying to resolve by reading the grammar was, is it
> permissible (or eve required) for a server to respond with 501 to an AUTHINFO
> USER with a username containing spaces.  However, given the above problem, I
> am unable to determine the answer from the document itself.

It is an interesting question, thanks!

I for one reckon it is a pretty good situation to answer 503.
According to RFC 3977:

   If the server recognizes the command but
   does not provide an optional feature (for example, because it does
   not store the required information), or if it only handles a subset
   of legitimate cases (see the HDR command, Section 8.5, for an
   example), the response code 503 MUST be returned.

Here, AUTHINFO USER/PASS is recognized but does not provide the
"white space" support and only handles a subset of legitimate
users and passwords!
(Continue reading)

Permalink | Reply | 2 comments |
headers
Antti-Juhani Kaijanaho | 14 May 2009 23:42
Picon

Re: [NNTP] RFC 4643 user-pass-char question

On Thu, May 14, 2009 at 11:23:45PM +0200, Julien ÉLIE wrote:
> I for one reckon it is a pretty good situation to answer 503.
> According to RFC 3977:
>
>   If the server recognizes the command but
>   does not provide an optional feature (for example, because it does
>   not store the required information), or if it only handles a subset
>   of legitimate cases (see the HDR command, Section 8.5, for an
>   example), the response code 503 MUST be returned.
>
>
> Here, AUTHINFO USER/PASS is recognized but does not provide the
> "white space" support and only handles a subset of legitimate
> users and passwords!

Rather depends on whether it is considered a syntax error (which is what I read
the draft 9 wording to require) or, as you say, an unimplemented optional
feature.  (OTOH, I find the whole 501/503 distinction rather confusing in
practice.)

One could even make the case that the server MAY respond with 481 (failed
authentication - no such user here).

--

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/
Permalink | Reply | 1 comment |
headers
Julien ÉLIE | 15 May 2009 00:06
Favicon

Re: [NNTP] RFC 4643 user-pass-char question

Hi,

>> I for one reckon it is a pretty good situation to answer 503.
>>
>> Here, AUTHINFO USER/PASS is recognized but does not provide the
>> "white space" support and only handles a subset of legitimate
>> users and passwords!
>
> Rather depends on whether it is considered a syntax error (which is what I read
> the draft 9 wording to require) or, as you say, an unimplemented optional
> feature.

It is not a big deal.  I think 503 is nicer here, knowing it is a special
(and RFC-allowed) feature to accept white spaces in AUTHINFO USER/PASS, even
in draft 9.
But please note that I do not see any problem in case you wish to answer 501.

> One could even make the case that the server MAY respond with 481 (failed
> authentication - no such user here).

481 implies that the syntax was valid and fully understood by the news server.
481 is not a valid answer in this case.

--

-- 
Julien ÉLIE

« Farpaitement ! » (Obélix)
Permalink | Reply | 0 comments |

Gmane