ietf-nntp draft-ietf-nntpext-base-17

[Clive D.W. Feather]

Charles Lindsey said:
>>> p18. '?' in wildmats
>>>       This is supposed to work with UTF-8 chars. Clearly any existing
>>>       implementation of '?' will not so work.
>> True, but the change to UTF-8 is known to be incompatible.
>> Someone is confusing this with [...]. We agreed the wildmat text about a
>> year ago!
> Yes I know, but I cannot remember _why_ we allowed '?' to remain.

Because ? and * are useful. Note that * is required to do UTF-8 matching -
it MUST NOT match a partial UTF sequence.

> Not that
> I oppose it, but I still think it is not Bruce Lilly-proof :-( .

To quote Isaac Asimov quoting Sir Arthur C. Clarke: "So what?"

>>> p26. Extension labels and parameters
>>>       It would be useful to say what characters are allowed in these.

>> Um, what are you reading in the syntax that suggests just ASCII?
> Sorry, it doesn't say it there, but in 6.1.2 it says the extension-label
> MUST be in uppercase. Ergo it is a letter (but not necessarily an ASCII
> one). I think it safest to stick with ASCII

I've changed the text to require the label to be ASCII (currently it was
just uppercase letters).

>  and letters, digits and minus
> should be quite sufficient (ditto for parameters).

Parameters are required to be printable characters.

>>> p55.  "If the optional wildmat parameter is specified, the list is limited to
>>>       only the groups whose names match the wildmat (and therefore may
>>>       be empty)."
>>> 
>>>       I believe an empty list is possible even when no wildmat is provided.
>> If the server has no groups, right? Okay.
> If no new groups have been added since the server was setup.

Huh?

This is LIST ACTIVE.TIMES, right? In which case the specification doesn't
say that it can omit newsgroups arbitrarily.

Is this an issue? The current specification - at least as I would read it -
is that LIST ACTIVE, LIST ACTIVE.TIMES, and LIST NEWSGROUPS should produce
the same list of groups given the same wildmat or absence thereof.

>>> p80.  "o replacing such sequences by a "guessed" valid sequence (based on
>>>       properties of the UTF-8 encoding);"

>> Are you saying that, if I receive 0xC1 0x96, I MUST NOT convert it to 0x56?
> From RFC 2279bis:
>    Implementations of the decoding algorithm above MUST protect against
>    decoding invalid sequences.  For instance, a naive implementation may
>    decode the overlong UTF-8 sequence C0 80 into the character U+0000,
>    or the surrogate pair ED A1 8C ED BE B4 into U+233B4. Decoding
>    invalid sequences may have security consequences or cause other
>    problems.  See Security Considerations (Section 10) below.

It says "protect against". I see nothing in 2279bis that forbids such
decoding, but section 10 requires you to be careful.

I've added:

  In the first case, the implementation MUST ensure that any replacement
  cannot be used to bypass validity or security checks.  For example,
  the illegal sequence %xC0.A0 is an over-long encoding for US-ASCII
  space (%x20).  If it is replaced by the latter in a command line,
  this needs to happen before the command line is parsed into individual
  arguments.  If the replacement came after parsing, it would be
  possible to generate an argument with an embedded space, which is
  forbidden.  Use of the "replacement character" does not have this
  problem, since it is permitted wherever non-US-ASCII characters are.

> RFC 2279 said the same, and I wrote a similar wording into Usefor. There
> are also serious suggestions that if you see something that is not valid
> UTF-8 you MAY try to treat it as whatever Chinese charset you think it
> might be

Not in *my* specification.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive at davros.org>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |