Re: Feature expression syntax; quoted strings

Am I getting old?  I seem to remember going through this in
several times in previous lives.  

First, are you sure that anyone really wants to use a double quote
inside a string?  It is fairly common to disallow it when it is the
delimiter, which is the case here?  Second, are these use cases places
where a different method for encoding the double quote (such as
URL-encoding) already exists?  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?

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.

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.

				regards,
					Ted Hardie
					

> 
> Folks,
> 
> In looking through RFC 2533, I note that a string value for a feature may 
> not contain a double quote character, there being no escape mechanism 
> within a string.  (This was lifted from RFC 2234, which has alternative 
> mechanisms for describing specific individual characters.)  On reflection, 
> it seems that assuming that a feature value can never contain a double 
> quote character could cause problems in the future.
> 
> I am thinking that there should probably be an escape mechanism defined so 
> that a quote character can be included in a string -- using a backslash 
> escape character is the technique that strings to mind, so that special 
> constructs '\\' and '\"' within a string are introduced.
> 
> I am not aware of any current use of RFC2533 which would be impacted by 
> such a change.
> 
> If this change is felt to be a Good Thing, it will have some impact on the 
> feature-hash draft (section 3.1.1: description of normalization logic).
> 
> Process question:  in view of the CONNEG WG being wound up, what is the 
> process for moving the work to draft standard, as and when implementations 
> are created?
> 
> #g
> 
> ------------
> Graham Klyne
> ([email protected])
>