Subject: Feature expression syntax; quoted strings

From: Graham Klyne <[email-masked]>
Date: Thu, 06 Apr 2000 11:05:30 +0100

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-masked])

---

From: [email-masked]
Date: Mon, 10 Apr 2000 10:34:30 -0700 (PDT)

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

---

From: Graham Klyne <[email-masked]>
Date: Tue, 11 Apr 2000 10:10:26 +0100

>several times in previous lives.

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

>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
>URL-encoding) already exists?

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

>   Third, since this definition of

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.

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

>it would be given a new RFC number.

Thanks.

#g

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