draft-ietf-nntpext-base-03.txt some comments

Paul Overell paulo at turnpike.com
Thu Jan 15 07:07:25 PST 1998


>9.1.2 AUTHINFO GENERIC
>  AUTHINFO GENERIC authenticator arguments...
>
>  AUTHINFO GENERIC is used to identify a specific entity to the
>  server using arbitrary authentication or identification
>  protocols. The desired protocol is indicated by the
>  authenticator parameter, and any number of parameters can be
>  passed to the authenticator.
>
>  When authorization is required, the server will send a 450
>  response requesting authorization from the client.
>
>  The client should enter AUTHINFO GENERIC followed by the
>  authenticator name and the arguments if any.  The
>  authenticator and arguments must not contain the sequence
>  "..".

What is the reason for this, rather odd, restriction?

>  The server will attempt to engage the server end
>  authenticator; similarly, the client should engage the client
>  end authenticator.  The server end authenticator will then
>  initiate authentication using the NNTP sockets (if appropriate
>  for that authentication protocol), using the protocol
>  specified by the authenticator name.  These authentication
>  protocols are not included in this document, but are similar
>  in structure to those referenced in RFC 1731[7] for the IMAP-4
>  protocol.
>

Saying "similar in structure" rather unsatifactory.  Can we not reference the
actual protocols?  Are they SASL protocols (RFC2222) ? 


>  If the server returns 501, this means that the authenticator
>  invocation was syntactically incorrect, or that AUTHINFO
>  GENERIC is not supported.  The client should retry using the
>  AUTHINFO GENERIC command.

This last sentence be "The client should retry using the AUTHINFO USER and PASS
commands".

[snip]

>14. Augmented BNF[10] Syntax for NNTP Commands
>
>This syntax defines the non-terminal "command". The non-terminal
>"parameter" is used for command parameters whose syntax is
>specified elsewhere. The syntax is in alphabetical order. Note
>that ABNF strings are case insensitive.
>
>  article-command = "ARTICLE" [1*WSP (msg-id / article-number)]
>     *WSP CRLF
>  article-number = 1*16DIGIT
>  augument = parameter ; excluding sequence ".."
>  authenticator = parameter ; excluding sequence ".."
>  authinfo-generic-command = "AUTHINFO" 1*WSP "GENERIC" 1*WSP
>  authenticator *(1*WSP argument) *WSP CRLF
>  authinfo-pass-command = "AUTHINFO" 1*WSP "PASS" 1*WSP password
>     *WSP CRLF
>  authinfo-user-command = "AUTHINFO" 1*WSP "USER" 1*WSP sername
>     *WSP CRLF
>  body-command = "BODY" [1*WSP (msg-id / article-number)] *WSP
>     CRLL

      ^^^^
      CRLF

[snip]

>  wildmat = 1*("*" / "?" / wildmat-exact / wildmat-set / "\"
>     %x21-FF)
>  wildmat-exact = %x21-29 / %x2B-3E / %x40-5A / %x5D-FF
>     ; exclude space * ? [ \
>  wildmat-non-hyphen = %x21-2C / %x2E-FF ; exclude space -
>  wildmat-set = "[" ["^"] ["]" / "-"]
>     *(wildmat-non-hyphen ["-" wildmat-non-hyphen])
>     ["-"] "]"


When I originally proposed and submitted the ABNF syntax for inclusion in the
draft the wildmat was defined in terms of single octet characters, now that
wildmat uses UTF-8 the syntax needs modification.


  UTF-8-non-ascii = %xC0-FF 1*(%x80-BF) ; UTF-8 encoding of non-ASCII character

  wildmat = 1*("*" / "?" / wildmat-exact / wildmat-set /
     "\" (%x21-7F / UTF-8-non-ascii))

  wildmat-exact = %x21-29 / %x2B-3E / %x40-5A / %x5D-7F / UTF-8-non-ascii
     ; exclude space * ? [ \

  wildmat-non-hyphen = %x21-2C / %x2E-7F / UTF-8-non-ascii ; exclude space -

  wildmat-set = "[" ["^"] ["]" / "-"] *(wildmat-non-hyphen ["-"
     wildmat-non-hyphen]) ["-"] "]"


I have allowed any character to be escaped by a backslash, is this correct?
The text in 5. suggests that only [ * \ ? may be escaped.

-- 
Paul Overell                                        T U R N P I K E  Ltd



More information about the ietf-nntp mailing list