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

From: Antti-Juhani Kaijanaho <[email-masked]>
Date: Thu, 14 May 2009 23:22:10 +0300

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
USER with a username containing spaces.  However, given the above problem, I
am unable to determine the answer from the document itself.

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/

---

From: Russ Allbery <[email-masked]>
Date: Thu, 14 May 2009 13:32:31 -0700

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

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

Hm.  Yeah.  We were talking about charset and I think I missed entirely
the implications for whitespace.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Julien ÉLIE <[email-masked]>
Date: Thu, 14 May 2009 23:23:45 +0200

Hi Antti-Juhani,

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

Any comments about that?

-- 
Julien ÉLIE

« Deux informaticiens discutent vers le 2 janvier :
  -- Qu'est ce que tu as pris comme résolution cette année ?
  -- 1024 × 768, et toi ? »

---

From: Antti-Juhani Kaijanaho <[email-masked]>
Date: Fri, 15 May 2009 00:42:19 +0300

> "white space" support and only handles a subset of legitimate

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

---

From: Julien ÉLIE <[email-masked]>
Date: Fri, 15 May 2009 00:06:32 +0200

Hi,

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

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