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

Cyrus Daboo <> Fri, 21 September 2012 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D34921F86C3; Fri, 21 Sep 2012 09:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.408
X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ORdoO53EYYFC; Fri, 21 Sep 2012 09:20:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6921721F8768; Fri, 21 Sep 2012 09:20:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D684630A3EC2; Fri, 21 Sep 2012 12:20:44 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4G1ZOpZ3CFfh; Fri, 21 Sep 2012 12:20:44 -0400 (EDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 2FA7C30A3EB2; Fri, 21 Sep 2012 12:20:42 -0400 (EDT)
Date: Fri, 21 Sep 2012 12:20:39 -0400
From: Cyrus Daboo <>
To: Michael Angstadt <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="3323"
Cc: Calsify <>, CardDAV <>
Subject: Re: [VCARDDAV] Progressing draft-daboo-ical-vcard-parameter-encoding-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Sep 2012 16:20:46 -0000

Hi Michael,
Thanks for your comments:

--On September 21, 2012 11:56:12 AM -0400 Michael Angstadt 
<> 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 

     ; 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"

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