Subject: Re: draft-ietf-nntpext-base-03.txt some comments

From: [email-masked] (Stan Barber)
Date: Thu, 15 Jan 1998 09:35:51 CST

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

Chris Lewis will have to comment on this.

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

Chris Lewis will have to comment on this.

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

Okey.

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

Okey.

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

In the original wildmat, this was true. However with UTF-8, it may be necessary
to extend the escape capability. Anyone have comments here?
-- 
Stan   | Academ Consulting Services        |internet: [email-masked]
Olan   | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob
Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

---

From: "Martin J. Duerst" <[email-masked]>
Date: Wed, 21 Jan 1998 21:40:52 +0900

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

I hope you are aware of the fact that UTF-8 can be defined
more exactly. The above expression captures everything you
want to capture if you have only legal UTF-8, but won't
exclude erroneous sequences. Probably that's enough for
our purposes.

> to extend the escape capability. Anyone have comments here?

You need escaping for those characters that do their work
defining the wildcard expressions. If [ * \ ? are the only
characters used for wildcard syntax, or if others can be
escaped otherwise (e.g. ]), you don't need to escape them.

As using non-ASCII characters in wildcard expressions would
mean that some people have difficulties using them, this
will probably never happen. So you don't need to escape them.

Regards,   Martin.

---

From: [email-masked] (Charles Lindsey)
Date: Thu, 22 Jan 1998 15:48:11 GMT

>will probably never happen. So you don't need to escape them.

If you follow the precedent of DRUMS, they allow '\' in front of any
character (well, only the 7bit ones in their case, of course). This makes
life simpler because, if you are not sure whether a particular character
needs escaping or not, then you can safely excape it anyway.

-- 
Charles H. Lindsey ---------At Home, doing my own thing-------------------------
Email:     [email-masked]   Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506       Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5