Subject: [VCARDDAV] JSON representation

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Jun 2012 19:07:22 -0600

Dear VCARDDAV WG,

My colleague Raghu Bhat and I have submitted the initial version of a
JSON representation for vCard4, and would welcome your feedback.

http://www.ietf.org/id/draft-bhat-vcarddav-json-00.txt

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 07 Jun 2012 01:28:11 -0400

> http://www.ietf.org/id/draft-bhat-vcarddav-json-00.txt

Cool!  vCard+JSON will be nice when it comes to automation.

A few things.  I don't agree that the type can always be ascertained
from the media type of the file.  This assumes well-behaved servers.  I
would think there is value in including an umbrella class to specify
that this is a vcard.  Could you not embed this into some other JSON
structure where it would be good to know that the type of this object is
a vCard?

Figure 4: The JSON is not equivalent to the plain text vCard format.
The JSON is missing the version :-).

I think there should be an example of CLARK notation when it comes to
vCard+JSON extensibility.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Support Engineer  ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: "Raghurama Bhat (ragbhat)" <[email-masked]>
Date: Thu, 7 Jun 2012 07:48:00 -0700

Hi Joe,

Please see my comments below.

Thanks,

--Raghu

Sent from my iPad

> structure where it would be good to know that the type of this object is
[Raghu] You make a good point about well behaved servers. But here is our reasoning. 1. It is  rare that you call an API OR click on a link and you don't know what response you get 2. Most often you will be using a language mapping to map this to a Java/Javascript/C++ Object. A level of indirection is going to be quite inconvenient.

When this is embedded in some other structure, it is going to be the value part of a property/value pair. Property part would indicate what this object is.

> The JSON is missing the version :-).

[Raghu] thanks for pointing out the error. Will fix it.
> vCard+JSON extensibility.
[Raghu] Will look into that
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 07 Jun 2012 07:52:29 -0700

Hi Peter,

> http://www.ietf.org/id/draft-bhat-vcarddav-json-00.txt

Folks at CalConnect have been working on a JSON format for iCalendar. Right 
now looks like we differ quite a lot on our thinking of how the format 
should work. Below is an example of what our current thinking is.

There are some important points here:

1) vCard vs iCalendar model: iCalendar is more complex in that it allows 
for embedded sub-components, so there is potentially an need for extra 
layers in the JSON model too.

2) Property cardinality issues: we discussed for quite a while how to 
handle the case of properties that can occur one or more times. The choice 
you have made, where the JSON value of such a property is either a string 
or a list was one we ruled out. That was partly based on feedback from some 
folks already using JSON who said the "irregular" nature of such a 
construct makes parsing harder - i.e. you need to write code to detect the 
difference between a string or a list. As a result we chose a model where 
properties always have a "regular" behavior - they contain just one value - 
and instead we allow for multiple properties (which leads to the next 
point).

3) Property names as JSON object names: since a JSON object cannot have the 
same object name used more than once, this lead us to "regularize" the 
property object model in JSON to use "name", "parameters" and "value" 
object names, with the value of the "name" object being that of the 
property name. We also used "component" instead of "name" to allow us to 
easily distinguish between a property and a sub-component.

4) Serialization speed: iCalendar objects can be large (e.g. a calendar 
subscription "feed"). We wanted it to be possible to incrementally 
serialize an iCalendar object into JSON. If we choose the model where 
properties with the same name are places in a single JSON object with a 
list value, we would be forced to potentially parse the entire iCalendar 
object before being able to start emitting any JSON (since properties can 
appear in any order, a multi-occurring property "X" could be the very first 
one and the very last one - we would be forced to wait for the very end of 
the iCalendar stream to see that the JSON "X" value needs to be a list). We 
have folks that need to be able to stream and serialize large iCalendar 
objects, so this is an important factor.

5) Naming issues: specifically there is no guarantee that a parameter name 
does not match a value type name. This is a problem that both xCard and 
xCal dealt with by encapsulating all parameters inside a <parameters> 
element. The same issue exists in JSON, hence the use of a "parameters" 
name in the property object, as opposed to "promoting" parameters to 
top-level items within the overall property JSON object. We also chose to 
encapsulate the values inside a "value" object in JSON. That was partly to 
help deal with the "regularization" issue - e.g. the DTSTART property can 
have either date-time or date value types. When trying to extract the value 
from JSON that requires the consumer to "test" to see which one is present.

Our plan, as always, is to bring this work to the IETF - we are planning to 
do that as soon as we can but other things have been keeping us busy. As 
always, we are looking for more input from real JSON experts on some of the 
issues outlined above and of course we are fully open to 
refining/redesigning the object model as consensus grows on what is 
correct. Hopefully we can get a draft out soon, but I did want to present 
some of our key thoughts now so that we can ensure some semblance of 
similarity between jCard and jCal.

{
  "component": "vcalendar",
  "contents": [
    {
      "name": "version",
      "value": {
        "text": "2.0"
      }
    },
    {
      "name": "calscale",
      "value": {
        "text": "GREGORIAN"
      }
    },
    {
      "name": "prodid",
      "value": {
        "text": "-//Example Inc.//Example Calendar//EN"
      }
    },
    {
      "component": "vevent",
      "contents": [
        {
          "name": "uid",
          "value": {
            "text": "4088E990AD89CB3DBB484909"
          }
        },
        {
          "name": "dtstart",
          "parameters": {
            "tzid": "US/Eastern"
          },
          "value": {
            "date-time": "2008-10-06T12:00:00"
          }
        },
        {
          "name": "dtstamp",
          "value": {
            "date-time": "2008-02-05T19:12:24Z"
          }
        },
        {
          "name": "summary",
          "value": {
            "text": "Planning meeting"
          }
        }
      ]
    }
  ]
}

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Jun 2012 10:57:17 -0400

> http://www.ietf.org/id/draft-bhat-vcarddav-json-00.txt

Cool!

Let me say first that it's a bit strange seeing a draft with my personal 
info sprinkled all over it. ;)

Here's some feedback...

Overall I think this is great. The most important issues I see (detailed 
below) are the clash between parameter and value type namespaces, and 
the representation of groups. IMHO what you have is acceptable, it just 
needs more precise text and justification.

In xCard we have a Relax NG schema defining exactly the format. There's 
no equivalent in your draft. This looseness makes me concerned about 
interoperability. Would it be possible to have a schema for JSON? Maybe 
ABNF?

> A JavaScript Object Notation (JSON) Representation for vCard
>                 draft-bhat-vcarddav-json-00

We already have vCard and xCard. Suggestion: call this jCard.

>        "gender": { "sex" : "M" },

This is super ugly. I know that's how it is in xCard, but xCard is what 
it is and is super ugly in various other ways. It would be nice if we 
could have simply:

"gender": "M"

>        "org": {
>            "type": "work",
>            "text": "Viagenie"

Shouldn't this be

        "org": {
            "type": "work",
            "text": ["Viagenie"]
        },

?

I hope not. What you have is fine. But it needs justification.

> For example, the "FN" property
>    is mapped to the fn property.

vCard properties are case-insensitive, so there is no mapping here. You 
might say instead that the JSON representation prefers lowercase 
property names.

> Value contains a text string that
>    corresponds to the vCard property's value.

What about integers? Floats? Booleans? Can they be expressed with native 
JavaScript types or do they need to be stringified?

>        "tel": {
>        "type": [ "voice", "video" ],
>        "uri": "tel:+1-555-555-555"
>        }

This assumes that the parameter namespace is disjoint from the value 
type namespace. This is true for now, but is not required by vCard 4. 
Maybe add an IANA consideration to the effect that in the future 
parameter names and value type names must not clash?

> properties with cardinality of
>    more than one are converted to a JSON array object

This means that property order is not guaranteed to be preserved when 
round-tripping JSON <-> vCard. I think it's acceptable, but it should be 
pointed out.

Also, do JSON dictionaries preserve key order? If not, that's another 
reason why property order wouldn't be preserved.

> The group construct
>    (Section 3.2 in [RFC6350]) is represented with the JSON object of the
>    same name.  For example:
>
>    {
>        "version" : "4.0"
>        "contact": {
>            "fn": "...",
>            "email": "..."
>        },
>        "media" : {
>            "photo": "..."
>        },
>        "categories": "..."
>    }
>
>              Figure 3: Mapping of lists and structured values
>
>    ... is equivalent to:
>
>    BEGIN:VCARD
>    VERSION:4.0
>    contact.FN=...
>    contact.EMAIL=...
>    media.PHOTO=...
>    CATEGORIES=...
>    END:VCARD
>
>                      Figure 4: Plain vCard equivalent

Ouch. What happens if I have a group named "version"?

> If there is no VALUE parameter
>    specified, it is treated as equivalent to VALUE=text.

Proposal: instead of "text" unconditionally, make it default to the 
default value type of the property. So that you could simply write:

"bday": "--0203"

>    BEGIN:VCARD
>    VERSION:4.0
>    EMAIL;VALUE=text;type=work:[email-masked]
>    GEO;VALUE=uri;type=work:geo:46.766336,-71.28955
>    BDATE;VALUE=date:--0203
>    END:VCARD
>
>                      Figure 6: Plain vCard equivalent

s/BDATE/BDAY/

Also, the FN property is mandatory.

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: Joe Marcus Clarke <[email-masked]>
Date: Thu, 07 Jun 2012 11:31:28 -0400

> [Raghu] You make a good point about well behaved servers. But here is our reasoning. 1. It is  rare that you call an API OR click on a link and you don't know what response you get 2. Most often yo…

What if the server returns a JSON error object or a jCard depending on
whether or not an error occurred, but didn't set the the content-type
correctly?  Sure, this is recoverable in the code, but if there was a
guaranteed vcard container, one could check for that.

> When this is embedded in some other structure, it is going to be the value part of a property/value pair. Property part would indicate what this object is.

Unless it's a generic like "object" : { }, which would leave it up to
the code to cast to the correct specific type.

Joe

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Jun 2012 17:42:52 +0200

On 2012-06-07 16:57, Simon Perreault wrote:
> ...
> ...

No.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jun 2012 09:53:32 -0600

On 6/7/12 9:31 AM, Joe Marcus Clarke wrote:
>> [Raghu] You make a good point about well behaved servers. But here
>> is our reasoning. 1. It is  rare that you call an API OR click on a
>> link and you don't know what response you get 2. Most often you
>> will be using a language mapping to map this to a
>> Java/Javascript/C++ Object. A level of indirection is going to be
>> quite inconvenient.
> 
> What if the server returns a JSON error object or a jCard depending
> on whether or not an error occurred, but didn't set the the
> content-type correctly?  Sure, this is recoverable in the code, but
> if there was a guaranteed vcard container, one could check for that.
> 
>> 
>> When this is embedded in some other structure, it is going to be
>> the value part of a property/value pair. Property part would
>> indicate what this object is.
> 
> Unless it's a generic like "object" : { }, which would leave it up
> to the code to cast to the correct specific type.

Hi Joe,

In an earlier iteration we had a "wrapper" indicating that the data is a
JSON-encoded vCard but Raghu convinced me it wasn't necessary. I don't
think it would be harmful in include that, and I see your point about
generic structures like "object". I'll give it further thought.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jun 2012 10:10:39 -0600

Hi Simon, thanks for your feedback. Comments inline.

> info sprinkled all over it. ;)

We thought it would be valuable to show the same data as in the other
representations.

> interoperability. Would it be possible to have a schema for JSON? Maybe

Raghu wanted to add a JSON schema in -00 but I convinced him to wait
until -01. :)  We would follow this expired I-D:

http://datatracker.ietf.org/doc/draft-zyp-json-schema/

> We already have vCard and xCard. Suggestion: call this jCard.

Yes, that's what we have for the file extension in the media type
registration. Works for me more generally.

> it is and is super ugly in various other ways. It would be nice if we

I like the simplicity, but I wonder if we're losing information. Would
you suggest that we do the same thing for all properties? For example:

"bday": "--0203"

"anniversary": "20090808T1430-0500"

> I hope not. What you have is fine. But it needs justification.

Why would use an array (an ordered collection of values) when there is
only one value? We were aiming for simplicity.

> might say instead that the JSON representation prefers lowercase

Good point.

> JavaScript types or do they need to be stringified?

IMHO it would be good to express them with native types.

> type namespace. This is true for now, but is not required by vCard 4.

I had not understood that from the vCard4 spec.

> parameter names and value type names must not clash?

Wouldn't that belong in rfc6350bis?

> reason why property order wouldn't be preserved.

As Julian pointed out, order isn't preserved. We'll add a note about
this in the text.

> Ouch. What happens if I have a group named "version"?

Ouch. Don't do that. :)

But seriously, this requires more thought. At least on my part.

> default value type of the property. So that you could simply write:

Yes, that's better (see above).

> Also, the FN property is mandatory.

True. We'll fix that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jun 2012 10:18:00 -0600

On 6/7/12 8:52 AM, Cyrus Daboo wrote:
> Hi Peter,
> 
> --On June 6, 2012 7:07:22 PM -0600 Peter Saint-Andre
> <[email-masked]> wrote:
> 
> Folks at CalConnect have been working on a JSON format for iCalendar.
> Right now looks like we differ quite a lot on our thinking of how the
> format should work. Below is an example of what our current thinking is.

Hi Cyrus,

I can see why you pursued that "regularization" strategy. I don't quite
agree with it yet, but I understand your perspective. I'll reply again
once I've had a chance to chat with my co-author.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 07 Jun 2012 09:20:26 -0700

Hi Peter,

> only one value? We were aiming for simplicity.

So this is one case where I would argue for a "regular" syntax - namely one 
that does not need to special case each property. i.e. the a JSON generator 
should not have to care what the cardinality of particular properties are - 
they should just write out each one, whether or not they occur multiple 
times. Having to special case cardinality leads to the need to build such 
rules into the generator for every "known" property and then "guess" what 
might be appropriate for new properties not yet registered or newly 
registered yet not accounted for. That will pose a major issue for 
extensibility. I would argue that a "regular" syntax is simpler than what 
you have now (with the trade off that it is more "verbose"). I think it 
will would greatly improve quality of code/interoperability to avoid 
special casing properties etc

That said, some properties will need to be special cased - namely 
structured ones - but those are more manageable.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Jun 2012 12:47:00 -0400

> "anniversary": "20090808T1430-0500"

bday and anniversary are different from gender. They are single 
date-and-or-time values by default. Whereas gender is a compound property.

The gender examples from vCard could be expressed like this:

      GENDER:M
      GENDER:F
      GENDER:M;Fellow
      GENDER:F;grrrl
      GENDER:O;intersex
      GENDER:;it's complicated

"gender": "M"
"gender": "F"
"gender": ["M", "Fellow"]
"gender": ["F", "grrrl"]
"gender": ["O", "intersex"]
"gender": ["", "it's complicated"]

or even possibly:
"gender": "it's complicated"

You can see I'm not arguing for regularity...

> only one value? We were aiming for simplicity.

I guess regularity would dictate using an array even for a single value 
because there is the possibility of multiple values...

> Wouldn't that belong in rfc6350bis?

Yes, but if jCard depends on it then maybe it would be quicker to just 
add it to jCard.

Simon

---

From: "Raghurama Bhat (ragbhat)" <[email-masked]>
Date: Thu, 7 Jun 2012 12:07:37 -0700

------------------------------------------------------------------------
-----------------------------------------
The gender examples from vCard could be expressed like this:
     GENDER:M
      GENDER:F
      GENDER:M;Fellow
      GENDER:F;grrrl
      GENDER:O;intersex
      GENDER:;it's complicated

"gender": "M"
"gender": "F"
"gender": ["M", "Fellow"]
"gender": ["F", "grrrl"]
"gender": ["O", "intersex"]
"gender": ["", "it's complicated"]
------------------------------------------------------------------------
-----------------------------------------
I like the simplicity for the simple case, but aren't we losing some
information in cases 3-6 above? You would not know which one is the
value and which one is the parameter unless you rely on order.  I don't
believe JSON converters are required to preserve order.

Thanks,

--Raghu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Simon Perreault
Sent: Thursday, June 07, 2012 9:47 AM
To: Peter Saint-Andre
Cc: [email-masked]
Subject: Re: [VCARDDAV] JSON representation

On 2012-06-07 12:10, Peter Saint-Andre wrote:
>> This is super ugly. I know that's how it is in xCard, but xCard is 
>> what it is and is super ugly in various other ways. It would be nice 
>> if we could have simply:
>>
>> "gender": "M"
>

bday and anniversary are different from gender. They are single
date-and-or-time values by default. Whereas gender is a compound
property.

      GENDER:M
      GENDER:F
      GENDER:M;Fellow
      GENDER:F;grrrl
      GENDER:O;intersex
      GENDER:;it's complicated

"gender": "M"
"gender": "F"

or even possibly:

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Jun 2012 15:12:27 -0400

I'm not sure I'm following you. You mean JSON lists may be arbitrarily 
reordered? If this is the case then there may be many more problems...

Simon

---

From: "Raghurama Bhat (ragbhat)" <[email-masked]>
Date: Thu, 7 Jun 2012 12:14:32 -0700

Yes. That is what I mean. You cannot rely on element order in JSON
arrays to be preserved

--Raghu

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: Thursday, June 07, 2012 12:12 PM
To: Raghurama Bhat (ragbhat)
Cc: Peter Saint-Andre; [email-masked]
Subject: Re: [VCARDDAV] JSON representation

On 2012-06-07 15:07, Raghurama Bhat (ragbhat) wrote:
> value and which one is the parameter unless you rely on order.  I 
> don't believe JSON converters are required to preserve order.

Simon

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Jun 2012 21:18:33 +0200

> Yes. That is what I mean. You cannot rely on element order in JSON

Sorry?

I think you are confusing array members with object members.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Jun 2012 15:19:38 -0400

On 2012-06-07 15:14, Raghurama Bhat (ragbhat) wrote:
> You cannot rely on element order in JSON
> arrays to be preserved

Are you really sure?

http://stackoverflow.com/questions/7214293/is-the-order-of-elements-in-a-json-list-maintained

Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jun 2012 13:19:51 -0600

> because there is the possibility of multiple values...

Yes, it would.

> Yes, but if jCard depends on it then maybe it would be quicker to just

Well, if we're asking IANA to change its registration procedures for
vCard parameter names and value type names, then that belongs in
6350bis. If we're making a note regarding criteria that expert reviewers
and the IESG might want to take into account, then it seems acceptable
to do that in the jCard spec (perhaps flagging it as something that
needs to be addressed more officially in 6350bis).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 Jun 2012 15:21:19 -0400

> needs to be addressed more officially in 6350bis).

Works for me!

Simon

---

From: "Raghurama Bhat (ragbhat)" <[email-masked]>
Date: Thu, 7 Jun 2012 12:28:15 -0700

Ok. I take back what I said. If we want to rely on order (Which I am not
too sure is the right thing to do), JSON spec will allow us to do so.

Thanks,

--Raghu

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: Thursday, June 07, 2012 12:20 PM
To: Raghurama Bhat (ragbhat)
Cc: Peter Saint-Andre; [email-masked]
Subject: Re: [VCARDDAV] JSON representation

On 2012-06-07 15:14, Raghurama Bhat (ragbhat) wrote:
> You cannot rely on element order in JSON arrays to be preserved

Are you really sure?

http://stackoverflow.com/questions/7214293/is-the-order-of-elements-in-a
-json-list-maintained

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 11 Jun 2012 14:33:16 -0400

On 2012-06-11 14:18, Joe Hildebrand wrote:
> I'm ok with relying on order in the places where vCard relies on order.  I
> detest it as a protocol design decision, but it makes the interop much
> easier, such that we don't have to come up with field names where none
> exist.

The bigger issue IMHO is: should we insist that JSON preserve the order 
of properties? If we don't care about ordering, we may use a dictionary 
as the root data structure, as proposed in the draft. Otherwise, 
something more complex would be needed.

RFC6350 doesn't say anything about order, except that VERSION must come 
first. Any well-behaved vCard consumer needs to be able to handle any 
ordering. So if round-tripping between vCard and JSON wouldn't preserve 
order, we would still have the same vCard as far as RFC6350 is concerned.

As a aside, an RFC6350bis should say that ordering of properties and 
parameters is not to be relied on for any purpose.

Simon

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 11 Jun 2012 12:18:56 -0600

-- 
Joe Hildebrand

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 11 Jun 2012 12:35:51 -0600

I don't care about the order of properties.  The streaming use cases of
CardDAV don't really apply, except, perhaps, for a collection of vCards.

-- 
Joe Hildebrand

---

From: "Raghurama Bhat (ragbhat)" <[email-masked]>
Date: Mon, 11 Jun 2012 11:39:19 -0700

In this case, vCard relies on Order but xCard does not.  (I am talking
about Gender value and parameter, not properties in general)
Personally, I think the self-describing nature of xCard is better for
JSON mapping to align with. I don't  see what the interop issue is. Full
conversion can be supported in both directions without any loss of
information.

Thanks,

--Raghu

-----Original Message-----
From: Joe Hildebrand (jhildebr) 
Sent: Monday, June 11, 2012 11:36 AM
To: Simon Perreault
Cc: Raghurama Bhat (ragbhat); [email-masked]
Subject: Re: [VCARDDAV] JSON representation

On 6/11/12 12:33 PM, "Simon Perreault" <[email-masked]>
wrote:

>> I'm ok with relying on order in the places where vCard relies on 
>> order.  I detest it as a protocol design decision, but it makes the 
>> interop much easier, such that we don't have to come up with field 
>> names where none exist.
> 
> The bigger issue IMHO is: should we insist that JSON preserve the 
> order of properties? If we don't care about ordering, we may use a 
> dictionary as the root data structure, as proposed in the draft. 
> Otherwise, something more complex would be needed.
> 
> RFC6350 doesn't say anything about order, except that VERSION must 
> come first. Any well-behaved vCard consumer needs to be able to handle

> any ordering. So if round-tripping between vCard and JSON wouldn't 
> preserve order, we would still have the same vCard as far as RFC6350
is concerned.

--
Joe Hildebrand

---

From: Simon Perreault <[email-masked]>
Date: Mon, 11 Jun 2012 14:52:00 -0400

> about Gender value and parameter, not properties in general)

You're talking about "component" order.

Yes, vCard relies on order to parse components. xCard doesn't since it 
uses different XML tags.

> conversion can be supported in both directions without any loss of

As long as you can reproduce the same component ordering in vCard, 
there's no issue here.

Simon