Subject: [calsify] Escaping dquote in a parameter value

From: Cyrus Daboo <[email-masked]>
Date: Tue, 19 Jun 2012 22:56:34 -0400

Hi,
As I am sure most people are aware, a double-quote character is forbidden 
to appear in a parameter value in both vCard and iCalendar. Yet there is a 
need to preserve double-quotes in a parameter value. So I am going to 
propose an extension to the specifications whereby a new escape mechanism 
is introduced solely for the purpose of allowing d-quote in a parameter 
value in a backwards compatible manner.

My proposal is to use ^ (0x5e) as an escape character, with only the 
following two sequences allowed:

^^ - represents a single ^ character
^' - represents a single d-quote character

I ruled out use of \ because some parsers erroneously eat that, and it 
would also be tempting to use \" which is definitely not possible because 
the dquote cannot appear.

I also ruled out & (XML/HTML entity style) and % (URI style) style escaping 
as being too general - we don't need to escape arbitrary characters - only 
dquote. Also, I think & and % are already in common use in parameter values 
that have URIs, so would end up being escaped themselves a lot more. I 
suspect ^ is one of the least used characters and so the need to escape the 
escape character is less.

Obviously there would need to be some backwards compatibility statement in 
regard to what to do with existing values with a single ^. I would suggest 
any combination that is not one of the above two, should be left alone when 
parsing. But when generating, it would be escaped as ^^.

There are probably some other ascii symbols that are infrequently used too, 
that we could pick if there are strong arguments against ^, but for now I 
am happy with ^.

Thoughts?

-- 
Cyrus Daboo

---

From: Jack <[email-masked]>
Date: Wed, 20 Jun 2012 07:56:44 +0100

On 20/06/2012 03:56, Cyrus Daboo wrote:
> Hi, As I am sure most people are aware, a double-quote character is
> forbidden to appear in a parameter value in both vCard and iCalendar.
>  Yet there is a need to preserve double-quotes in a parameter value.
> So I am going to propose an extension to the specifications whereby a
> new escape mechanism is introduced solely for the purpose of allowing
>  d-quote in a parameter value in a backwards compatible manner.
>
> ^^ - represents a single ^ character ^' - represents a single d-quote
> character
>
> I ruled out use of \ because some parsers erroneously eat that, and
> it would also be tempting to use \" which is definitely not possible
>  because the dquote cannot appear.

However "\" is already specified in RFC2445 as the escape character in
TEXT (4.3.11).

That section specifies that a DQUOTE is not to appear in a TEXT; but it
also specifies that a ";" shall not appear in a TEXT, and then goes on
to specify that a ";" must be escaped thus: "\;". So I read it as saying
(as clearly as anything is said in that document) that a DQUOTE should
be escaped thus: "\"".

-- 
Jack.
_______________________________________________
calsify mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/calsify

---

From: Jack <[email-masked]>
Date: Wed, 20 Jun 2012 07:56:44 +0100

-- 
Jack.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 20 Jun 2012 09:53:28 -0400

Hi Jack,

> (as clearly as anything is said in that document) that a DQUOTE should

First please use RFC5545 as your reference not RFC2445.

Second, the syntax for a parameter value, as opposed to a property value, 
is different. Here is the 5545 syntax:

     param-value   = paramtext / quoted-string

     paramtext     = *SAFE-CHAR

     quoted-string = DQUOTE *QSAFE-CHAR DQUOTE

     QSAFE-CHAR    = WSP / %x21 / %x23-7E / NON-US-ASCII
     ; Any character except CONTROL and DQUOTE

     SAFE-CHAR     = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
                   / NON-US-ASCII
     ; Any character except CONTROL, DQUOTE, ";", ":", ","

So a DQUOTE is not allowed in either paramtext or quoted-string, and there 
is no affordance for any kind of escape character.

It is also true that CONTROL characters are not allowed. Now that I think 
of it, there have been situations I have come across where line feeds at 
least were needed in a parameter value. That suggest that perhaps my 
proposed ^ escape mechanism should be broadened to allow some specific 
CONTROLs, e.g.:

^n  - LF
^r  - CR
^t  - HTAB

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 20 Jun 2012 09:53:28 -0400

Hi Jack,

     paramtext     = *SAFE-CHAR

^n  - LF
^r  - CR
^t  - HTAB

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 20 Jun 2012 10:22:10 -0400

Hi Simon,

--On June 20, 2012 9:58:01 AM -0400 Simon Perreault 
<[email-masked]> wrote:

> Interesting. I follow your reasoning and agree with your conclusion.
>
> Have you actually come across a parameter value that needed to contain a
> dquote?

yes, there are some cases where it is handy to include additional 
parameters on existing properties. e.g., consider IMPP which is specified 
as a URI for an IM service:

IMPP:xmpp:[email-masked]

Often times, people use arbitrary "display names" (handles) in their IM 
clients, and it would be handy to have those listed in the vcard via a 
parameter on the IMPP property. However, there is no restriction on using a 
DQUOTE in such display names, so we need to allow for DQUOTEs in the 
parameter value.

A similar issue exists for the (now defunct) SOCIALPROFILE property, which 
I still have an interest in using and reviving.

In iCalendar, a good example is the CN parameter (Common Name). Some 
systems allow users to configure their own names so they can add "phrases" 
in the middle, e.g. 'Cyrus "Mulberry Dude" Daboo'. Or perhaps a room or 
resource has a "quoted" title in its name too. So again, there is a need to 
support DQUOTE.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 20 Jun 2012 10:22:10 -0400

Hi Simon,

-- 
Cyrus Daboo