Subject: [VCARDDAV] vCardXML conversion

From: Arnaud Quillaud <[email-masked]>
Date: Mon, 18 Apr 2011 15:02:10 +0200

Looking at 
http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-09#section-6 .

This may have been discussed already but when converting from xml to 
iCalendar, xCal states that:
<<
When converting component, property and parameter values, the names
    SHOULD be converted to uppercase.  Although iCalendar names are case
    insensitive, common practice is to keep them all uppercase following
    the actual definitions in [RFC5545].
On the other hand, I dont see anything equivalent in vCardXML (why not 
xCard BTW ?).

When converting from vCard to vCard XML:
<<
If the property has parameters, they get translated as-is
          (without lowercasing of parameter names, removal of backslash
          escaping, and removal of quoting) into sub-elements of the
<parameters> element

* "without lowercasing of parameter names": Why ? The rest of the 
document seems to indicate the opposite.
* "without removal of escaping and quoting": this is just because the 
actual unescaping is described at a latter stage, right ?
* "into subelements of the parameters element": since all parameters now 
have a "value typing" subelement, shouldn't that be described (i.e. if 
the parameter is a recognized one, use the known schema. If the 
parameter is itself unknown, wrap its value in a <text> subelement).

Arnaud Quillaud

---

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Apr 2011 09:43:09 -0400

> document seems to indicate the opposite.

The intent was to try to make round-tripping work. However, I now
realize two things:
- We cannot rely on vCard implementations to preserve case once it's
converted.
- It breaks the recommendation in vcardrev-19 section 3.3.

So I suggest that instead we specify that new xCard property and
parameter element names MUST be lower-case. How about this?

   New XML vCard property and parameter element names MUST be lower-
   case.  This is necessary to ensure that round-tripping between XML
   and plain-text vCard works correctly.

> actual unescaping is described at a latter stage, right ?

I don't think so. At this point I'm thinking that it is wrong and I will
just remove it.

> parameter is itself unknown, wrap its value in a <text> subelement).

Agreed.

How about this new text?

      *  If the property has parameters, they get translated into sub-
         elements of the <parameters> element.  Each sub-element's name
         is set to the corresponding parameter's lowercased name.  Each
         sub-element's content is a single <test> element whose content
         is copied as-is from the corresponding parameter's value.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 18 Apr 2011 10:02:10 -0400

Hi Simon,

>          is copied as-is from the corresponding parameter's value.

<test> -> <text>

However, that is not entirely correct as parameter values other than <text> 
are allowed (e.g. GEO and TZ which both support URIs). Plus there is also 
the possibility of multi-valued parameters (comma-separated list) - those 
should appear as separate xml elements.
So better would be:

      *  If the property has parameters, they get translated into sub-
         elements of the <parameters> element.  Each sub-element's name
         is set to the corresponding parameter's lowercased name.  Each
         sub-element's content is one or more value type elements whose
         content is generated from the corresponding parameter's value.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Apr 2011 10:18:26 -0400

On 2011-04-18 10:02, Cyrus Daboo wrote:
> However, that is not entirely correct as parameter values other than
> <text> are allowed (e.g. GEO and TZ which both support URIs).

These directives are for the case when the converter doesn't know the
property. Should we say that known parameters applied on unknown
properties are known or unknown?

> Plus there
> is also the possibility of multi-valued parameters (comma-separated
> list) - those should appear as separate xml elements.

Again, not if the parameter is unknown.

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 18 Apr 2011 10:45:44 -0400

Hi Simon,

> Again, not if the parameter is unknown.

So Keith Moore brought up a good point on the xCal draft about what happens 
when converting iCalendar data containing a new (unknown) property into 
XML. If the converter has no knowledge about the new property it won't know 
what the default value type is. So a new property that defaults to a value 
of DATE-TIME, for example, would need to use the <date-time> element in 
xCal - but the converter won't know to do that. Now xCard also has the same 
problem.

The reason this is a problem is that an XML processor dealing with the xCal 
data could known about the new properties and therefore be expecting 
<date-time> as a value element. If it uses some form of validation it would 
likely fail if the converter used <text> as its default when <date-time> is 
expected.

So, one option is to introduce a new value type element <unknown> that can 
be used in such cases. This lets the XML processor know that the the value 
is the "raw" iCalendar type and if it wants the "native" xCal value it will 
need to parse that or roundtrip the xCal through xCal->iCalendar->xCal 
using a converter that knows about the new property. Here is some a 
proposal:

    When converting iCalendar into xCal: an property that does not include
    a "VALUE" parameter and whose default value type is not known, the XML
    value type element <unknown> MUST be used. The content of that element
    is the value text treated as if it were a property with "VALUE=TEXT".

    When converting xCal into iCalendar, any <unknown> property value 
elements
    are converted as if they were <text> value type elements. The 
containing property
    MUST NOT have a "VALUE" property parameter.

    When converting iCalendar into xCal: an unknown parameter value
    MUST use the <unknown> value type element, with its content set to
    the parameter value text, treated as if it were a TEXT value, or
    list of TEXT values.

    When converting from xCal into iCalendar, any <unknown> parameter
    value elements are converted as if they were <text> value type elements.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Apr 2011 10:56:03 -0400

On 2011-04-18 10:45, Cyrus Daboo wrote:
> So Keith Moore brought up a good point on the xCal draft about what
> happens when converting iCalendar data containing a new (unknown)
> property into XML. If the converter has no knowledge about the new
> property it won't know what the default value type is. So a new property
> that defaults to a value of DATE-TIME, for example, would need to use
> the <date-time> element in xCal - but the converter won't know to do
> that. Now xCard also has the same problem.

Right. We tried to handle that in the current text.

> The reason this is a problem is that an XML processor dealing with the
> xCal data could known about the new properties and therefore be
> expecting <date-time> as a value element. If it uses some form of
> validation it would likely fail if the converter used <text> as its
> default when <date-time> is expected.

Hmm....

> So, one option is to introduce a new value type element <unknown> that
> can be used in such cases. This lets the XML processor know that the the
> value is the "raw" iCalendar type and if it wants the "native" xCal
> value it will need to parse that or roundtrip the xCal through
> xCal->iCalendar->xCal using a converter that knows about the new
> property. Here is some a proposal:
> 

Sounds good! I'll adopt that for xCard.

What about a known parameter applied to an unknown property? Can we
assume its value is the same as it would be if it was applied to a known
property?

Thanks,
Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 18 Apr 2011 11:05:40 -0400

Hi Simon,

> Sounds good! I'll adopt that for xCard.

OK. I would like to hear from others that this makes sense...

> assume its value is the same as it would be if it was applied to a known

Actually I think we should probably have some text describing that point 
and making it clear that existing parameters should not be used in a 
fundamentally different way in new properties. Instead a new parameter 
should be defined. What that basically means is that it is not possible to 
extend existing parameters to support new value types. I think that is 
reasonable.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Apr 2011 11:13:40 -0400

On 2011-04-18 11:05, Cyrus Daboo wrote:
> should be defined. What that basically means is that it is not possible
> to extend existing parameters to support new value types. I think that
> is reasonable.

Extending parameters to support new value types is impossible in the
plain-text format. So it's pretty simple: if you use a new parameter
value type in XML, then your XML is unconvertible. In that case the
whole property would get embedded into an XML: property in vCard.

I think it's perfectly fine to create new XML-only stuff, as long as you
know what you're doing. Text explaining the consequences is good.

Simon