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

[Cyrus Daboo <[e-mail]>]

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