Re: Feature expression syntax; quoted strings

At 10:34 AM 4/10/00 -0700, [email protected] wrote:
>Am I getting old?  I seem to remember going through this in
>several times in previous lives.

Oops, sorry.  If we, did, I forgot.  (I suspect it's I who am getting old :-)

>First, are you sure that anyone really wants to use a double quote
>inside a string?

No I'm not.  That's why I ask.

>   It is fairly common to disallow it when it is the
>delimiter, which is the case here?

It is common, I believe, when there are alternative ways of expressing the 
same value (e.g. alternative quotes).

>   Second, are these use cases places
>where a different method for encoding the double quote (such as
>URL-encoding) already exists?

I am thinking specifically of string *values* for features, for which there 
is no alternative.

>   Third, since this definition of
>string has been in place from the beginning, is it unreasonable
>to presume that those designing the values to be used with this
>system have been taking it into account and taking appropriate
>action to avoid the problem?

Fair question.   (Part of my concern was that we might want to import 
definitions from other work which may not be aware of any such restriction.)

On reflection, I concede that we could define such imports to fit within 
the string syntax;  e.g. by using URL-style encoding for non-ASCII and 
quote characters.

>Last, please realize that we will not modify "string" at this point.
>If we absolutely must have a representation that allows double quotes,
>we will need to introduce a new value type.  That will cause a need to
>update the syntax and registration docs, which recycles everything at
>proposed.   It also seems to cause problems for our ITU friends,
>and may cause a serious deployment delay.

I understand this, and did not raise the issue lightly.

If we have already discussed this and decided that no quotes in values is 
OK, then I withdraw my comments.  Not recalling any such discussion, I felt 
it was better to raise the issue now than to leave it as a problem that 
would bite later.  I would be best pleased if we can say this is not a problem.

>To answer your other process question, anyone who has evidence that
>the requirements of Draft standard have been met by a standard currently
>at Proposed may submit that evidence to the relevant ADs for consideration.
>If they are satisified, they request that the IESG consider changing
>the document from Proposed to Draft.  If new, non-normative language
>is added or two documents combined (as would be the case for us), a
>new document would be submitted at the same time as the evidence and
>it would be given a new RFC number.

Thanks.

#g

------------
Graham Klyne
([email protected])