Subject: [VCARDDAV] Fwd: Last Call: <draft-daboo-et-al-icalendar-in-xml-08.txt> (xCal: The XML format for iCalendar) to Proposed Standard

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Apr 2011 09:57:29 -0600

Just FYI. This document is intended to be in sync with vcardxml
regarding XML structure, so folks here might want to review both
documents with that in mind...

-------- Original Message --------
Subject: Last Call: <draft-daboo-et-al-icalendar-in-xml-08.txt> (xCal:
The XML	format for iCalendar) to Proposed Standard
Date: Thu, 14 Apr 2011 08:20:20 -0700
From: The IESG <[email-masked]>
Reply-To: [email-masked]
To: IETF-Announce <[email-masked]>

The IESG has received a request from an individual submitter to consider
the following document:
- 'xCal: The XML format for iCalendar'
  <draft-daboo-et-al-icalendar-in-xml-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-05-12. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-daboo-et-al-icalendar-in-xml/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-daboo-et-al-icalendar-in-xml/

No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Filip Navara <[email-masked]>
Date: Thu, 14 Apr 2011 18:21:03 +0200

> documents with that in mind...

That's surely not the case, vcardxml uses different encoding for
parameters as far as I can see. This was apparently deliberate change
in vcardxml:

"o  All parameters now use value elements.  This affects type, and pref."

Aside from that there's another problem with the ENCODING parameter.
iCalendar (RFC 5545) is very vague with the definition and usage of
the ENCODING parameter and as such it is possible, albeit pretty
useless, to create the following property:

  "SEQUENCE;ENCODING=BASE64:MQ=="

At least one of the leading iCalendar parsing libraries actually has
such content in the .ics files in test suite.

draft-daboo-et-al-icalendar-in-xml states the following:

"As required by [RFC5545], the ENCODING paramater MUST be present and
set to "BASE64", and the VALUE parameter must be present and set to
"BINARY"."

and

"iCalendar uses a base64 encoding for binary data.  The base64
encoding MUST remain when converted to XML."

The problem is that this is in conflict with the vague definition in
RFC5545, where ENCODING=BASE64 can be used for non-BINARY values.

Best regards,
Filip Navara

---

From: Simon Perreault <[email-masked]>
Date: Thu, 14 Apr 2011 12:30:51 -0400

> "o  All parameters now use value elements.  This affects type, and pref."

The suggestion to do that came from a co-author of the xCalendar draft,
so I'm wondering why they're not also doing it...

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: Thu, 14 Apr 2011 12:44:37 -0400

Hi Simon,

> so I'm wondering why they're not also doing it...

My mistake - we do actually use "value" elements for parameters that are 
not text, but did not do that for text. We were going to change that so 
that all parameters use text and I missed that in my last revision. The 
intent is to follow what vCard now does for parameters.

-- 
Cyrus Daboo

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 14 Apr 2011 10:45:45 -0600

> intent is to follow what vCard now does for parameters.

Excellent. Cross-document review is a good thing. :)

Peter

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

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 14 Apr 2011 12:51:14 -0400

Hi Filip,

> RFC5545, where ENCODING=BASE64 can be used for non-BINARY values.

I think that is a very rare edge case but we should probably deal with it. 
How about adding a statement of the form:

"If an ENCODING=BASE64 parameter is present on a property that does not 
have VALUE=BINARY, the property MAY be converted into XML by removing the 
base64 encoding on the value and removing the ENCODING parameter".

Question is is that a MAY or a SHOULD...

-- 
Cyrus Daboo

---

From: Arnaud Quillaud <[email-masked]>
Date: Fri, 15 Apr 2011 14:41:53 +0200

On 04/14/2011 06:21 PM, Filip Navara wrote:
> On Thu, Apr 14, 2011 at 5:57 PM, Peter Saint-Andre<[email-masked]>  wrote:
We have

  seq = "SEQUENCE" seqparam ":" integer CRLF
        ; Default is "0"

        seqparam   = *(";" other-param)

where

other-param   = (iana-param / x-param)

      iana-param  = iana-token "=" param-value *("," param-value)
      ; Some other IANA-registered iCalendar parameter.

      x-param     = x-name "=" param-value *("," param-value)
      ; A non-standard, experimental parameter.

so I think the above is just invalid.

The encoding param is really just allowed on ATTACH as far as I can see.

Arnaud
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Apr 2011 12:41:36 -0600

> documents with that in mind...

I notice that the definitions for value types, parameters, and
properties are not always in sync. Do they need to be?

Here are two examples.

1. The "boolean" value.

a. vcardxml says:

value-boolean = element boolean { xsd:boolean }

b. icalendar-in-xml says:

   value-boolean = element boolean {
       ("TRUE" | "FALSE")
   }

The difference here is that W3C XML Schema defines two lexical
represenations for boolean: either "true"/"false", or "1"/"0".

http://www.w3.org/TR/xmlschema-2/#boolean

2. The "geo" parameter / property.

a. vcardxml says:

param-geo = element geo { value-uri }?

b. icalendar-in-xml says:

   property-geo = element geo {

       element parameters { empty }?,

       element value {
           element latitude  { text },
           element longitude { text }
       }
   }

/psa

---

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Apr 2011 14:51:21 -0400

> http://www.w3.org/TR/xmlschema-2/#boolean

Here I think icalendar-in-xml should be fixed.

>            element longitude { text }

Be careful, you're comparing a parameter against a property.

Both the vCard GEO property and parameter take a URI as value...

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 18 Apr 2011 14:56:09 -0400

Hi Peter,

> http://www.w3.org/TR/xmlschema-2/#boolean

The xCal spec does not use xsd: elements in its RelaxNG schema. Should it? 
I see that Simon seems to have gone to greater lengths to specify string 
patterns and the like to constrain values. For xCal we choose not to do 
that, preferring to keep the base schema simple on the understanding that 
validation of iCalendar semantics would require something a lot more 
complex (e.g. requiring DTEND > DTSTART etc).

So the question here is should xCal adopt the xsd: style value specs in 
xCard, or should xCard drop back to using simple RelaxNG { text } elements, 
or does it not matter?

>            element longitude { text }

GEO is itself defined differently in iCalendar (two floats) and vCard (geo 
uri) - so in this case the difference is valid. However, the xCal schema 
for GEO is wrong as it ought to use 'float' and not 'text'.

-- 
Cyrus Daboo