Re: [VCARDDAV] Progressing draft-daboo-ical-vcard-parameter-encoding-01

[Michael Angstadt <[e-mail]>]

Cyrus,

> BTW the ABNF comment in 6350 for QSAFE-CHAR and SAFE-CHAR is (approximately):
>
>    ; Any character except CTLs, DQUOTE, ...
>
> CTL is defined in ABNF as:
>
> CTL            =  %x00-1F / %x7F
>
> So technically that would exclude HTAB - i.e. the comment is not accurate, though the actual definition is.

Yeah, that's a error.  It's noted in the 6350 errata.

> Using a double-quote in the escape sequence won't work. Consider (example from the spec):
>
> ATTENDEE;CN="George Herman \"Babe\" Ruth":mailto:[e-mail]
>
> Existing iCalendar/vCard parsers know nothing about escape sequences in parameters.

Oh ok, that makes sense.

-Mike
http://code.google.com/p/ez-vcard

On Fri, Sep 21, 2012 at 12:20 PM, Cyrus Daboo <[e-mail]> wrote:
> Hi Michael,
> Thanks for your comments:
>
>
> --On September 21, 2012 11:56:12 AM -0400 Michael Angstadt
> <[e-mail]> wrote:
>
>> An escape sequence for the horizontal tab character is actually not
>> necessary.  Horizontal tab characters can be included in a parameter
>> value without needing to be escaped.  The ABNF definitions for
>> parameter values (in both the iCalendar and vCard specs) allow for
>> "WSP".  "WSP" is defined as being a space or horizontal tab character
>> (see RFC 5234 p.14).
>
>
> Yes, you are correct. I will remove HTAB escaping from the spec.
>
> BTW the ABNF comment in 6350 for QSAFE-CHAR and SAFE-CHAR is
> (approximately):
>
>     ; Any character except CTLs, DQUOTE, ...
>
> CTL is defined in ABNF as:
>
> CTL            =  %x00-1F / %x7F
>
> So technically that would exclude HTAB - i.e. the comment is not accurate,
> though the actual definition is.
>
> In 5545 the comment is:
>
> ; Any character except CONTROL, DQUOTE, ...
>
> And 5545 defines CONTROL itself:
>
> CONTROL       = %x00-08 / %x0A-1F / %x7F
>
> That explicitly excludes HTAB. So 5545 comment is correct.
>
>
>> Why not use the conventional backslash character for escaping?  The
>> vCard specs already state that the LABEL parameter of the ADR property
>> should use the "\n" sequence to escape newlines (RFC 6350 p.33-34).
>>
>> So, the escape sequences could instead be:
>>
>> +---------------------+-------------------------------+
>> | Escape Sequence     | Character                     |
>> +---------------------+-------------------------------+
>> | \" (U+002F, U+0022) | U+0022 (Quotation Mark)       |
>> | \n (U+002F, U+006E) | U+000A (Line Feed)            |
>> | \\ (U+002F, U+002F) | U+002F (Backslash)            |
>> +---------------------+-------------------------------+
>
>
> Using a double-quote in the escape sequence won't work. Consider (example
> from the spec):
>
> ATTENDEE;CN="George Herman \"Babe\" Ruth":mailto:[e-mail]
>
> Existing iCalendar/vCard parsers know nothing about escape sequences in
> parameters. So they will parse the parameter value as  'George Herman \' -
> i.e. from the first occurrence of " to the second occurrence. However, the
> text after the second double-quote ought to be either a : or a ; but is not
> - so the parser could legitimately throw an error at that point because the
> data is invalid.
>
> Bottom line is a double-quote cannot be escaped using a sequence that itself
> includes a double-quote for backwards compatibility reasons. Hence the
> choice of using single-quote in the spec.
>
> In terms of the choice to not use \ - I have seen some non-interoperable use
> of \ in parameters, and thus want to steer clear of that so that we can
> achieve guaranteed, reliable interoperability. Also, given that double-quote
> gets changed to single-quote in the escape sequence for a parameter, but not
> for a value, I did not want to give the impression that the same escape
> mechanism can be used for both (which could lead to other issues such as an
> implementation incorrectly escaping a ; as \; as opposed to quoting the
> parameter value).
>
> BTW Barry Lieba, who agreed to sponsor this document as AD, asked similar
> questions and we agreed that it would be good to include justification of
> the choices, as per above, as an appendix in the draft and I intend to add
> that once the informal last call is over.
>
> --
> Cyrus Daboo
>