Subject: [Jcardcal] Registration of the UNKNOWN data type

From: Philipp Kewisch <[email-masked]>
Date: Tue, 30 Apr 2013 16:11:32 +0200

I've noticed that I mentioned that the UNKNOWN type is to be used just 
for jCard. I should mention that it is to be used for jCard and jCal at 
least.

The question is how the registration is done best. Right now the jCard 
document registers the type, and in jCal I would reference the 
registration in the jCard document. Does this make sense? Or should 
registration of the type be done separately, or in both documents?

Philipp

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 30 Apr 2013 10:33:39 -0400

Hi Philipp,

> registration of the type be done separately, or in both documents?

It needs to be separate because the IANA registries for vCard and iCalendar 
are separate. You need to base the registration off the procedures 
described in the base specs RFC 6350 and RFC 5545 respectively.

Note also that this registration will require an "expert" review as 
described in the IANA sections of those base specs. That just means sending 
an email to the expert mailing lists for each one. Since I am one of the 
designated experts for iCalendar, I will recuse myself (as I am a document 
co-author) and will leave handling of this up to Bernard Desruisseaux. I 
believe Simon is the vCard expert.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Tue, 30 Apr 2013 17:07:18 +0200

Le 2013-04-30 16:33, Cyrus Daboo a écrit :
> described in the IANA sections of those base specs. That just means
> sending an email to the expert mailing lists for each one.

I believe that is done by IANA as part of their process for creating a 
new record in any registry having "Expert Review" as registration 
procedure. So no need for the draft editor himself to send email himself.

Simon

---

From: Philipp Kewisch <[email-masked]>
Date: Tue, 30 Apr 2013 17:18:20 +0200

> procedure. So no need for the draft editor himself to send email himself.
Since its just Bernard remaining to be contacted, it probably won't hurt 
to CC him.

Bernard, in case you haven't been following jcardcal, we are planning to 
regsister an "UNKNOWN" value data type to RFC5545 to solve the issue 
unknown default value types when roundtripping between the jCal 
representation and iCalendar.

You can find details here: 
http://tools.ietf.org/html/draft-ietf-jcardcal-jcal-02#section-5

Philipp

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 30 Apr 2013 14:30:00 -0400

Hi Philipp,

I would suggest to use UNKNOWN-DEFAULT to make it clear that it should 
only be used when the default value type is unknown and not when the 
actual value type is unknown for any other reason.

Just so you know...

In theory, the default value type of Non-Standard Properties ("X-" 
properties) is always known.
See: http://tools.ietf.org/html/rfc5545#section-3.8.8.2

    Value Type:  The default value type is TEXT.  The value type can be
       set to any value type.

But since, in practice, many calendar applications (clients and servers) 
are doing a poor job of specifying/handling the value type of 
Non-Standard Properties it may be a good idea to apply this solution to 
them as well (as you did).

Furthermore, in theory, the default value type of IANA Properties is 
also always known.
See: http://tools.ietf.org/html/rfc5545#section-3.8.8.1

    Value Type:  The default value type is TEXT.  The value type can be
       set to any value type.

The consequence is that any new registered property that isn't of TEXT 
value type should always specify the VALUE parameter.  An errata should 
probably be filed to get this fixed/clarified.

Cheers,
Bernard

On 30/04/2013 11:18 AM, Philipp Kewisch wrote:
>> I believe that is done by IANA as part of their process for creating 
>> a new record in any registry having "Expert Review" as registration 
> Since its just Bernard remaining to be contacted, it probably won't 
> hurt to CC him.
>
> Bernard, in case you haven't been following jcardcal, we are planning 
> to regsister an "UNKNOWN" value data type to RFC5545 to solve the 
> issue unknown default value types when roundtripping between the jCal 
> _______________________________________________
> jcardcal mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jcardcal

---

From: Philipp Kewisch <[email-masked]>
Date: Tue, 30 Apr 2013 23:13:06 +0200

Hi Bernard,

thanks for your comments.

> actual value type is unknown for any other reason.
About the naming, aside from "unknown", the suggestion of using 
"default" has previously come up. Note also that xCal uses an <unknown> 
element, we chose to align the naming to this element. See also this 
message: http://www.ietf.org/mail-archive/web/jcardcal/current/msg00075.html

I admit I missed this message when updating the text, I should 
definitely make it more clear that its an "unknown default", but I'd 
still prefer sticking with "UNKNOWN" as the name for mentioned alignment 
reasons.

> But since, in practice, many calendar applications (clients and 
> servers) are doing a poor job of specifying/handling the value type of 
> Non-Standard Properties it may be a good idea to apply this solution 
> to them as well (as you did).
Also, afair vCard doesn't directly specify how such properties are 
handled, other than there being no "outside registration or 
standardization". Using this unknown type helps keep jCard and jCal in line.

At least I now know why I didn't see the unknown type issue earlier, as 
I started these specs with jCal. I will slightly modify the text in jCal 
to mention these cases, but as you mention its probably still a good 
idea to use the "unknown" solution.
> probably be filed to get this fixed/clarified.
It still doesn't change the situation for implementations that do not 
know about the type. If they assume TEXT and an extension defines 
something else, they will still apply TEXT-style escaping, which would 
be wrong.

Philipp