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

Paul Overell paulo at turnpike.com
Thu Jan 22 01:37:43 PST 1998


In article <199801220305.MAA11952 at sh.w3.mag.keio.ac.jp>, Martin J.
Duerst <duerst at w3.org> writes
>Stan Barber answered Paul Overell:
>
>> >   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.

Of course.

> The above expression captures everything you
>want to capture if you have only legal UTF-8, but won't
>exclude erroneous sequences.

This is exactly what I was trying to do.  The definition of UTF-8 does
not belong in RFC977bis, implementors must refer to the UTF-8
documentation [RFC2044]. 

> Probably that's enough for
>our purposes.
>

Agreed.

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

So, should we allow the redundant escaping of non meta-characters?  If
this breaks existing implementations then perhaps the answer should be
no.  Otherwise I can see no reason to not allow it, since it means that
a user who is unsure as to which are the meta-characters can apply the
maxim "when in doubt, escape".

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



More information about the ietf-nntp mailing list