Subject: [Jcardcal] Remaining issues in jCard

From: Philipp Kewisch <[email-masked]>
Date: Wed, 03 Apr 2013 01:42:39 +0200

Hello Folks,

I've uploaded a new jcard draft, please doublecheck the changes I've
made. Now only a few minor issues left:

>    o  [RFC6350] doesn't define any kind of stream for multiple vcard
>       elements.  For similarity with the jCal draft, I have added a
>       "vcardstream".  Is this wanted and does the name fit?  (Maybe
>       rather "jcardstream" ?)
>
>    o  vCard defines the VERSION property MUST come first.  Do we need to
>       do the same here?

Unless there are objections, I think we should stay with "vcardstream"
and not mandate the version property coming first.

Bert, Peter, as there are only minor issues, I believe the next step is
to open up the jcard draft for discussion in other WGs? If so, I'd
appreciate if you could get this going.

Thanks,
Philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Apr 2013 18:45:25 -0600

On 4/2/13 5:42 PM, Philipp Kewisch wrote:

> Bert, Peter, as there are only minor issues, I believe the next
> step is to open up the jcard draft for discussion in other WGs? If
> so, I'd appreciate if you could get this going.

<hat type='chair'/>

Hi Philipp,

When this WG was getting started, Bert and I pinged all of the
relevant working groups and pointed them here. We'll be happy to poke
them all again when we start Working Group Last Call ("WGLC") on the
jCard and jCal specs so that everyone knows they have one more chance
to provide feedback. And it seems that WGLC will be imminent, which is
great because it keeps us on schedule. :-)

Bert and I will have a chat about the timing and then post again to
this list.

Thanks!

Peter

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

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 2 Apr 2013 20:54:05 -0400

Le 2013-04-02 à 20:45, Peter Saint-Andre <[email-masked]> a écrit :

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> to provide feedback.

- some of these groups may or may not be fully aware of the details. Maybe only a few individuals. Some were said: don't do "this" (as address formats), instead use our great standard vcard, with the upcoming json encoding.
- a suggestion: some shepherding to make sure it does not pass through.  I see sending unicast messages to the document editors in these wg (as well as wg ml), so they have 2 wakeup calls.

Marc.

> And it seems that WGLC will be imminent, which is
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRW3ulAAoJEOoGpJErxa2px9cP/2ncBa5tjyRploalmyRBicbh
> exYf3v9GNlEyiWlyAsy6LkGxdnacJzX8yMscRdmldnpwoT0f0AagcQYVRiZkWH59
> mTHVo42DdxgstIFEu+XhU0sEq7flw5vDj0mUDinWnLA9TPsxmQgW+DTdw5Zxk9ae
> AdUnqGIDN7kFMCnQw4lj4LkKsTUckmb7t0tGr9bZGLxch9x3Wn3SGfrLqINCZfvG
> JfM+WFLJplrNxzCODkJNmeLEORF12i+0Jd6BlxdPK3zW16Wy23hqAHnzxrvDpjGu
> XdyIf2FKdugeh8gEbNh6ruHxmYA9fsgZRY5Z7WCWYGPjOYCpiVFa1BaSow1Fj7oY
> ++qCGNHOwz72A7lZU+0pdaZimly06/PqO84cD/JlKdn4W62NYC6rZxyMRNIQfN81
> ObSrHNM6/J231WZb1D0iHYfNTYGiLx1nyxHF19IxUajrt4yZVNmPhluyynlyhy/0
> iT25+4+AmFzPs3JBRLBNbErNnDorA8hWdrF7xSDb45GlSziRSZS9fQ8qMqS0DAdh
> EJtsQNt4kICC46C0XRlyRDdg0OktniuGK84m/dumK3qKQUQtWbY3rAXqxDjdda+H
> UATiuXZ+jHTgIm8dEyTbpTsQf4AMKmBBA97zw6gtDd7Ez/odlOp/4S19PAJmdJ8O
> eWm3ZSUpbSxFSMUNhy+c
> =n/cX
> -----END PGP SIGNATURE-----
> _______________________________________________
> jcardcal mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jcardcal

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Apr 2013 21:28:43 -0600

On 4/2/13 6:54 PM, Marc Blanchet wrote:
>>>> Bert, Peter, as there are only minor issues, I believe the
>>>> next step is to open up the jcard draft for discussion in
>>>> other WGs? If so, I'd appreciate if you could get this
>>>> going.
> 
> <hat type='chair'/>
> 
> Hi Philipp,
> 
> relevant working groups and pointed them here. We'll be happy to
> poke them all again when we start Working Group Last Call ("WGLC")
> on the jCard and jCal specs so that everyone knows they have one
> more chance to provide feedback.
> 
>> - some of these groups may or may not be fully aware of the
>> details. Maybe only a few individuals. Some were said: don't do
>> "this" (as address formats), instead use our great standard
>> vcard, with the upcoming json encoding. - a suggestion: some
>> shepherding to make sure it does not pass through.  I see sending
>> unicast messages to the document editors in these wg (as well as
>> wg ml), so they have 2 wakeup calls.

Good idea. Bert and I will reach out to the document editors, WG
chairs, and WGs as a whole.

Peter

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Apr 2013 11:27:09 +0200

The new version looks good. I especially like the example with the 
"gender" property in section 3.3.

> Unless there are objections, I think we should stay with "vcardstream"

ok

> and not mandate the version property coming first.

ok

Ship it! :)

Simon

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 3 Apr 2013 08:43:23 -0300

Section 3.1 says that:
 > the specification uses date/time and utc-offset
 >  values aligned with the complete representation, extended format of
 >  [ISO.8601.2004]

(there is similar text in sections 3.5.3, 3.5.4 and 3.5.5)

Note that:

- The extended format for truncated representations is not defined in ISO
8601:2004 (i.e. you won't find "--MM-DD" in 8601:2004) because truncated
representations are *only* defined in ISO 8601:2000.

- A complete representation is defined (in both editions) as a "representation
that includes all the date and time components associated with the
expression". That means that abbreviated representations such as "--MM-DD"
(truncated), and "YYYY-MM" (reduced precision ) are not complete.

Proposed text (for section 3.1):
 > the specification uses date/time and utc-offset
 >  representations aligned with the complete representation, extended format
of
 >  [ISO.8601.2004] and a subset of representations other than complete
aligned with the extended format of [ISO.8601.2000].

The mention of "complete representation" in section 3.5.7 is fine, because the
representation of a TIMESTAMP value is always complete.

In section 3.5.11, while the description (correctly) does not require a
"complete" representation, it is not clear from the text that the minute part
is optional. Compare with ABNF in RFC 6350, pag. 10:
   utc-offset = sign hour [minute]

Best Regards

Javier Godoy

----------------
Universidad Nacional del Litoral
Facultad de Ingeniería y Ciencias Hídricas
Santa Fe - Argentina

---

From: Michael Angstadt <[email-masked]>
Date: Wed, 3 Apr 2013 08:05:46 -0400

I think "vcardstream" is fine.  Also, I think it makes sense for version to
come first, since the properties are stored in an array and cannot be
accessed by name.  But then again, "4.0" is the only valid value, so
basically, there's no real need to parse it at all. :)

Small comment: I think the section on structured values (section 3.3.1.3)
should be clarified to emphasize the fact that a structured value is
based on using a semi-colon for a delimiter and not based on the value's
ABNF definition.  If it is based on the ABNF, then only ADR, N, and ORG
should be considered structured, since they make use of the "component" and
"list-component" definitions.  GENDER and CLIENTPIDMAP do not.

Suggested change to the first paragraph (apologies for the formatting):

The vCard specification defines properties with structured values,
   for example GENDER or ADR.  A structured value is defined as a value
that contains multiple text components, delimited by the SEMICOLON
character.  In jCard,
   the property value is an array containing one element for each text
   component.

Thanks,
Mike

On Tuesday, April http://tools.ietf.org/html/draft-ietf-jcardcal-jcard-01,
2013, Philipp Kewisch wrote:

>  Hello Folks,
>
> I've uploaded a new jcard draft, please doublecheck the changes I've made.
> Now only a few minor issues left:
>
> Unless there are objections, I think we should stay with "vcardstream" and
> not mandate the version property coming first.
>
> Bert, Peter, as there are only minor issues, I believe the next step is to
> open up the jcard draft for discussion in other WGs? If so, I'd appreciate
> if you could get this going.
>
> Thanks,
> Philipp
>
>
>
>
>

---

From: Michael Angstadt <[email-masked]>
Date: Wed, 3 Apr 2013 08:25:43 -0400

Expanding on Javier's mention of date formats, I vaguely recall there being
a reason for why vCard 4 decided *not* to adopt the extended format for
dates (i.e. to leave out the dashes and colons).  I think it had something
to do with the fact that there exist some ambiguities when the extended
format and reduced accuracy formats are used together.  Does this ring a
bell for anyone?  I don't have the time to look into this now, but will
later.

Thanks,
Mike

On Wednesday, April 3, 2013, Javier Godoy wrote:

> ______________________________**_________________
> jcardcal mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/jcardcal<https://www.ietf.org/mailman/listinfo/jcardcal>
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 03 Apr 2013 15:05:53 +0200

Le 2013-04-03 14:25, Michael Angstadt a écrit :
> Expanding on Javier's mention of date formats, I vaguely recall there
> being a reason for why vCard 4 decided *not* to adopt the extended
> format for dates (i.e. to leave out the dashes and colons).  I think it
> had something to do with the fact that there exist some ambiguities when
> the extended format and reduced accuracy formats are used together.
>   Does this ring a bell for anyone?  I don't have the time to look into
> this now, but will later.

I remember we decided to use the basic format because it allowed more 
flexiblity in the representation of dates than the extended format.

However I don't think we ever considered allowing both basic and 
extended, nor did we ever consider using extended plus a little bit of 
basic. Looking at the draft, I can't find any ambiguities. I think they 
intentionally eliminated all possible ambiguities.

Personally I think it would be less error-prone to just go with basic, 
so that there is no conversion between [vx]Card and jCard.

Simon

---

From: Michael Angstadt <[email-masked]>
Date: Wed, 3 Apr 2013 18:38:53 -0400

On Wed, Apr 3, 2013 at 9:05 AM, Simon Perreault <[email-masked]
> wrote:

> However I don't think we ever considered allowing both basic and extended,
> nor did we ever consider using extended plus a little bit of basic. Looking
> at the draft, I can't find any ambiguities. I think they intentionally
> eliminated all possible ambiguities.

Nevermind, I think it was a paragraph about reduced accuracy dates in the
vCard 4 specs that triggered my memory.  It mentions how YYYY-MM-DD is not
permitted because vCard 4 uses the basic format.

Section 4.3.1:

   Note the use of YYYY-MM in the second example above.  YYYYMM is
   disallowed to prevent confusion with YYMMDD.  Note also that
   YYYY-MM-DD is disallowed since we are using the basic format instead
   of the extended format.

In the case of jCard, YYYY-MM-DD *would* be allowed because it uses the
extended format.

I don't see any ambiguities either.  Sorry about the false alarm.

Mike

---

From: Bert Greevenbosch <[email-masked]>
Date: Sun, 7 Apr 2013 02:39:50 +0000

Hi Philipp,

[As an individual]

Indeed the draft looks quite good. I have a minor issue for our consideration:

Section 5 discusses the handling of unrecognised properties or parameters when converting between vCard and jCard. The draft specifies that when the "VALUE" property parameter of an unknown property in vCard shall be converted to a string object in jCard. What will be the associated JSON value type? I assume it will be "text"?

When converting from jCard back to vCard, the value type is explicitly maintained in vCard, unless it is equal to a known default value.

So if we have an object in vCard with a new default "VALUE" "foo". As it is the default it is not signalled, and an unknowing vCard/jCard converter will set the value type to "text" in jCard. Then when subsequently converting back to vCard, the converter will either notice the jCard value type is not equal to the default value type, or does not know the default value type either. In either case, it will add a "VALUE" property parameter "TEXT" in vCard.

Maybe one could consider to have a "default" value type in jCard instead, which is treated as "text", but when converting back to vCard leads to omission of the "VALUE" property parameter in vCard?

Or would an unknowing converter be allowed to convert a default "VALUE" property parameter in vCard to a unspecified (empty) value type in jCard?

Best regards,
Bert

---

From: Philipp Kewisch [mailto:[email-masked]] 
Sent: 2013年4月3日 7:43
To: [email-masked]
Cc: Peter Saint-Andre; Bert Greevenbosch
Subject: Remaining issues in jCard

Hello Folks,

I've uploaded a new jcard draft, please doublecheck the changes I've made. Now only a few minor issues left:

Unless there are objections, I think we should stay with "vcardstream" and not mandate the version property coming first.

Bert, Peter, as there are only minor issues, I believe the next step is to open up the jcard draft for discussion in other WGs? If so, I'd appreciate if you could get this going.

Thanks,
Philipp

---

From: Simon Perreault <[email-masked]>
Date: Sun, 07 Apr 2013 09:03:26 +0200

So you have:

X-UNKNOWN;VALUE=foo:bar

That should get converted into:

{ "x-unknown", {}, "foo", "bar" }

And vice versa.

Anything I'm missing?

Isn't this what the current text says?

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: Bert Greevenbosch <[email-masked]>
Date: Sun, 7 Apr 2013 07:35:59 +0000

Hi Simon,

[as an individual]

I mean:

   X-UNKNOWN:bar

would become

   { "x-unknown", {}, "text", "bar" }

and converting back

   X-UNKNOWN;VALUE=text:bar

where the "foo" in the first vCard was omitted because it is the default type, but after the conversion process it has become "text".

So maybe it should be as follows in jCard:

   { "x-unknown", {}, "default", "bar" }

or

   { "x-unknown", {}, "", "bar" }

Or do you think "X-..." fields always have the VALUE type property, and cannot have a default type? How about non "X-..." fields that become defined in a new RFC or a later version of vCard?

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: 2013年4月7日 15:03
To: [email-masked]
Subject: [Jcardcal] jCard round-tripping with unknown value types

So you have:

X-UNKNOWN;VALUE=foo:bar

And vice versa.

Anything I'm missing?

Simon

---

From: Simon Perreault <[email-masked]>
Date: Sun, 07 Apr 2013 09:46:22 +0200

Le 2013-04-07 09:35, Bert Greevenbosch a écrit :
> where the "foo" in the first vCard was omitted because it is the
> default type, but after the conversion process it has become "text".

Ah, I understand now! Yes, this is definitely a problem.

> { "x-unknown", {}, "", "bar" }

Second option makes most sense IMHO.

> Or do you think "X-..." fields always have the VALUE type property,
> and cannot have a default type? How about non "X-..." fields that
> become defined in a new RFC or a later version of vCard?

Both X- properties and standard-but-yet-unknown-to-the-converter 
properties may have a default type. We need to handle this.

Thanks for noticing this. This is important.

Simon

---

From: Michael Angstadt <[email-masked]>
Date: Mon, 8 Apr 2013 07:10:39 -0400

xCard has an "unknown" data type for this purpose.  Maybe this should be
used in jCard too for consistency.

>From section 6 of RFC 6351:

      *  Any property that does not include a "VALUE" parameter and
         whose default value type is not known MUST be converted using
         the value type XML element <unknown>.  The content of that
         element is the unprocessed value text.

Thanks,
Mike

On Sunday, April 7, 2013, Simon Perreault wrote:

> Both X- properties and standard-but-yet-unknown-to-**the-converter
> DTN made easy, lean, and smart --> http://postellation.viagenie.**ca<http://postellation.viagenie.ca>

---

From: Philipp Kewisch <[email-masked]>
Date: Sat, 13 Apr 2013 13:09:42 +0200

Sorry for the late reply. Indeed this is something that must be resolved.

I like the idea of using the "unknown" type as it matches xcal. We probably need to register it as a value type for rfc6350 and rfc5545 then though for the unlikely but possible case that someone wants an explicit VALUE=UNKNOWN.

Any objections on using "unknown" and registering it?

Philipp

On Apr 8, 2013, at 13:10, Michael Angstadt <[email-masked]> wrote:

> xCard has an "unknown" data type for this purpose.  Maybe this should be used in jCard too for consistency.
> 
> * Any property that does not include a "VALUE" parameter and whose default value type is not known MUST be converted using the value type XML element <unknown>. The content of that element is the unprocessed value text.
> 
> Thanks,
> Mike
> 
>> Both X- properties and standard-but-yet-unknown-to-the-converter properties may have a default type. We need to handle this.
>>

---

From: Michael Angstadt <[email-masked]>
Date: Sat, 13 Apr 2013 12:17:13 -0400

> Any objections on using "unknown" and registering it?

No objections. :)

---

From: Simon Perreault <[email-masked]>
Date: Sat, 13 Apr 2013 19:12:22 +0200

>> Any objections on using "unknown" and registering it?

Works for me!

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 14 Apr 2013 11:26:21 -0400

Hi Philipp,

--On April 13, 2013 1:09:42 PM +0200 Philipp Kewisch <[email-masked]> 
wrote:

> I like the idea of using the "unknown" type as it matches xcal. We
> probably need to register it as a value type for rfc6350 and rfc5545 then
> though for the unlikely but possible case that someone wants an explicit
> VALUE=UNKNOWN.
>
>

Go ahead for both vCard and iCalendar.

-- 
Cyrus Daboo

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 15 Apr 2013 01:17:42 +0000

Hi Philip, all,

(as an individual)

Indeed I think a new "unknown" value type can be used. But with this name there is a danger that it will be used for other reasons than an unknown default value type.

So when converting from jCard to vCard, will the jCard "unknown" value type be converted to a (new) vCard "unknown" value parameter, or will it be omitted?

In case "unknown" is only used for default value types, it should be omitted. But if "unknown" becomes used for other reasons, then it may not be the default value type, and after conversion the "unknown" value parameter needs to be present in the vCard. This again changes the semantics when round tripping.

The nice thing about name "default" is that it is less likely to be used for other purposes than indicating that the value type is the default value type.

Best regards,
Bert

---

From: [email-masked] [mailto:[email-masked]] On Behalf Of Philipp Kewisch
Sent: 2013年4月13日 19:10
To: [email-masked]
Subject: Re: [Jcardcal] jCard round-tripping with unknown value types

Philipp

Thanks,
Mike

[as an individual]

I mean:

X-UNKNOWN:bar

would become

and converting back

X-UNKNOWN;VALUE=text:bar

or

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 15 Apr 2013 09:51:05 +0200

> So when converting from jCard to vCard, will the jCard "unknown" value type be converted to a (new) vCard "unknown" value parameter, or will it be omitted?

xCard handles it like this:

       *  Any <unknown> property value XML elements are converted
          directly into vCard values.  The containing property MUST NOT
          have a "VALUE" parameter.

Source: https://tools.ietf.org/html/rfc6351#section-6

> The nice thing about name "default" is that it is less likely to be used for other purposes than indicating that the value type is the default value type.

How could "unknown" be used for other purposes once jCard registers it 
from IANA?

Simon

---

From: Bert Greevenbosch <[email-masked]>
Date: Mon, 15 Apr 2013 08:29:36 +0000

Hi Simon,

(as an individual)

<quote>
</quote>

Very good, that means that in xCard the <unknown> property value implicitely corresponds with the default value in vCard. So if we write something similar in jCard, the round tripping will go alright.

> How could "unknown" be used for other purposes once jCard registers it from IANA?

My reasoning is: since the naming implies that the value type is unknown, it could be anything unknown, whether default or not. I could e.g. imagine a conversion from a third party format into jCard. The conversion tool could be tempted to use "unknown" for any unsupported formats in the third party format, whether default or not.

Anyway, the this is maybe only a theoretical issue. As long as jCard "unknown" is omitted after conversion to vCard, we have solved our round tripping problem and everything is fine. The fact that the <unknown> property value already exists in xCard makes a good case for using the same name in jCard.

So I am fine with using "unknown".

Best regards,
Bert

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: 2013年4月15日 15:51
To: [email-masked]
Subject: Re: [Jcardcal] jCard round-tripping with unknown value types

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 15 Apr 2013 10:38:01 +0200

Le 2013-04-15 10:29, Bert Greevenbosch a écrit :
> My reasoning is: since the naming implies that the value type is
> unknown, it could be anything unknown, whether default or not. I
> could e.g. imagine a conversion from a third party format into jCard.
> The conversion tool could be tempted to use "unknown" for any
> unsupported formats in the third party format, whether default or
> not.

Right. So the jCard text would need to be carefully crafted to indicate
that the use is precisely to represent "unknown default" value types,
not just any kind of unknown.

> The fact that the <unknown> property value already exists in xCard
> makes a good case for using the same name in jCard.

That's my thinking too.

Simon

---

From: Philipp Kewisch <[email-masked]>
Date: Tue, 16 Apr 2013 16:36:31 +0200

While reading the documents to do these changes, I noticed one thing in 
our key design considerations:

>   * Round-tripping (converting a vCard instance to jCard and back)
>     will give the same semantic result as the starting point. For
>     example, all components, properties and property parameters are
>     guaranteed to be preserved, with the exception of those which have
>     default values.
>

This is exactly the text from xCal execpt of course using 
s/vCard/iCalendar/ s/jCard/xCal/.

I'm not saying we should drop this new concept, my email is more FYI. 
I'm going to change the design considerations now that we handle default 
types without any losses.

Philipp