Subject: [weirds] on the subject of vcard

From: Andy Newton <[email-masked]>
Date: Mon, 14 Jan 2013 16:06:00 +0000

All,

I started looking at the vCard JSON draft. You can find it here:
http://datatracker.ietf.org/doc/draft-bhat-vcarddav-json/

In my opinion there are a couple of issues we need to keep in mind:

First, the current draft expired over a month ago. Even if it were kept
current, it doesn't look like that draft has a working group home, and
therefore placing a dependency on it could delay the WEIRDS work. Our
working group could adopt it, but that seems rather odd as vCard is not
the focus of WEIRDS.

Second, the vCard JSON draft has a section carved out for a JSON schema.
At present, there is no standardized JSON schema language. I think making
our work depend on a JSON schema language could delay our deliverables.
And I say this as the author of the JSON Content Rules draft
(https://datatracker.ietf.org/doc/draft-newton-json-content-rules/)Š I.e.
I'm not willing to subject WEIRDS to my own JSON schema language
preferences.

While I do think vCard is a good idea, I'd like to also note that
supporting it has never been stated as a goal of this working group. Given
the timeline for our milestones, I propose the following compromise: let
us go forward with the current flat postal address structure, and when
vCard JSON comes to maturity we can revisit the issue and extend the
protocol to use vCard JSON.

Is this compromise acceptable? What do you all think?

-andy

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Jan 2013 17:31:40 +0100

> working group could adopt it, but that seems rather odd as vCard is not

By reusing vCard we will save time by not having to reinvent the wheel. 
But I agree it has its procedure cost. Hopefully we'll end up with a 
better protocol in roughly the same time.

I can apply some manpower behind this draft to help speed things up.

> I'm not willing to subject WEIRDS to my own JSON schema language

Easy fix IMHO: the schema section should be dropped from that draft.

> protocol to use vCard JSON.

The thing is, it's not just about postal addresses. I listed all the 
elements that would be replaced by a single vCard in an earlier mail.

Simon

---

From: Andy Newton <[email-masked]>
Date: Mon, 14 Jan 2013 23:46:07 +0000

>By reusing vCard we will save time by not having to reinvent the wheel.

Simon, I do not disagree with this.

>I can apply some manpower behind this draft to help speed things up.

As I said, WEIRDS is likely not the appropriate forum for vCard work.
Therefore a vCard JSON dependency would be unpredictable as to the
timeline needed to complete it.

>elements that would be replaced by a single vCard in an earlier mail.

You're quite right and good point. Let me amend the proposed compromise to
include all the elements you mentioned. We could place them under a single
sub-object to be be superseded by server operators when we can extend RDAP
to support vCard.

-andy

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Jan 2013 11:31:05 +0100

> timeline needed to complete it.

I'm not proposing that the jCard draft be adopted by WEIRDS, although it 
would be nice I guess. It can remain an individual draft, eventually 
being brought to IESG as AD-sponsored, I suppose.

FYI, there's an equivalent draft for iCalendar with a lot of traction. 
This has been published earlier today:

http://www.ietf.org/id/draft-kewisch-et-al-icalendar-in-json-01.txt
http://www.ietf.org/mail-archive/web/vcarddav/current/msg02688.html

jCard could be seen as a syntactical subset of jCalendar. So we just 
have to adapt to vCard what those guys are doing for iCalendar. IMHO 
it's not a big endeavour. I've done it before with XML, JSON should be 
way easier.

> sub-object to be be superseded by server operators when we can extend RDAP

That would work until people start asking (again) about i18n, character 
sets, languages, data formats, etc. I don't see how that proposal 
answers those questions.

Simon

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 15 Jan 2013 12:16:45 +0100

On Tue 15/Jan/2013 00:46:07 +0100 Andy Newton wrote:
>> The thing is, it's not just about postal addresses.
> 
> Let me amend the proposed compromise to include all the elements
> you mentioned. We could place them under a single sub-object

alternatively, a "flat" merge of the object parts boils down to
picking vCard type/names where available.  For example:

   "email": [
      {"type": "auto", "text": "[email-masked]" },
      {"type": "work", "text": "[email-masked]" }
   ]

instead of

   "emails": [ "[email-masked]", "[email-masked]" ]

> to be be superseded by server operators when we can extend RDAP to 
> support vCard.

resp., to be automagically recognized as a vCard extension whenever
the latter will get standardized.

jm2c

---

From: Andy Newton <[email-masked]>
Date: Tue, 15 Jan 2013 18:11:47 +0000

>sets, languages, data formats, etc. I don't see how that proposal

For the current data structures, we have that all worked out.

-andy

---

From: Pete Resnick <[email-masked]>
Date: Fri, 18 Jan 2013 16:12:37 -0600

On 1/15/13 4:31 AM, Simon Perreault wrote:
> I'm not proposing that the jCard draft be adopted by WEIRDS, although 
> it would be nice I guess. It can remain an individual draft, 
> eventually being brought to IESG as AD-sponsored, I suppose.

Just to let you know, the ADs and others are working out the logistics 
of moving jCard/jCal (and a bunch of other stuff) either into their own 
WG or to get them otherwise standardized. I am committed to making sure 
that jCard is ready for any WG that wishes to reference it. It will 
*not* be difficult to get it complete.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478