Re: [VCARDDAV] Proposal around escape character handling (2nd round)

Florian Zeitz <> Tue, 13 July 2010 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BFCB3A6B2F for <>; Tue, 13 Jul 2010 10:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qzXgPUaNYwAc for <>; Tue, 13 Jul 2010 10:25:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 648313A6B29 for <>; Tue, 13 Jul 2010 10:25:24 -0700 (PDT)
Received: from ([] helo=[]) by v64231 with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <>) id 1OYjEZ-00077L-Uq for; Tue, 13 Jul 2010 19:25:32 +0200
Message-ID: <>
Date: Tue, 13 Jul 2010 19:25:54 +0200
From: Florian Zeitz <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100624 Lanikai/3.1
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [VCARDDAV] Proposal around escape character handling (2nd round)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Jul 2010 17:25:25 -0000

On 13.07.2010 17:36, Simon Perreault wrote:
> On 2010-07-13 10:59, Cyrus Daboo wrote:
>> So there is a real problem here. For example, if in the future I define
>> a new property FOO that uses a ;-delimited compound value, then I want
>> to be sure that clients not aware of this property will properly
>> "round-trip" it. So if I send such a client this:
>> FOO:delimited;text\;string
> Right, there is a problem with the current text.
> Assume we specify that semicolons that are not component separators MUST
> be escaped. Then a client can correctly interpret this unknown property
> as having two components. And it will always output it exactly the way
> it received it. That fixes the problem, right?
> If so, this would point toward the acceptance of proposal 1.
> Simon
While I'm not strictly against this I wonder if this is really needed.
If we are working under the assumption that the client doesn't
understand the FOO property, can't we just say that it MUST NOT parse it
at all and replicate it exactly as received? (e.g. by storing it with a
I don't see the point of knowing that something I don't understand has
two components...

Florian Zeitz