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