Subject: xCal - resubmitted.

From: Doug Royer <[email-masked]>
Date: Mon, 08 Aug 2005 14:44:07 -0600

The xCal draft has been rewritten and submitted to the IETF.

I have an XSLT translation file that I will be releasing
soon on SourceForge that can translate an xCal object
back to an iCal object. I am waiting for SourceForge
to approve the project name.

Discussion takes place on [email-masked]

Copies of the draft at:

	http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
	http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
	http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml

JOIN the xCal mailing list at:

	http://inet-consulting.com/mailman/listinfo/xcal

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Aug 2005 11:08:31 +0200

>     http://inet-consulting.com/mailman/listinfo/xcal

Just two quick formal comments...:

1) Is it intentional that in the examples, the iCalendar container 
element is in no namespace?

2) I don't think the IETF will let you use something like 
"http://ietf.org/rfc/rfcXXXX.txt" as namespace name; but if they do, you 
probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead.

Best regards, Julian

---

From: "Cameron Stillion" <[email-masked]>
Date: Tue, 9 Aug 2005 02:35:09 -0700

2.2.1
	Are you minimizing the difference between the inherent unicode
capabilities of XML and the rather esoteric encoding requirements of
iCal? Simply wrapping the data in tags is not really enough...

2.2.2
	isomeric - I think you mean "isometric".  Ah, the difference one
character can make...

	also - why is it required to send an alternate MIME body part in
normal iCal format? Is this format designed to replace the old format?
Ultimately? If so, why should both be required? iCal readers of old can
read xcal via transform, and new applications can easily parse using a
standard xml parser... Why limit all uses of this to also implement the
old way of doing things? This seems counter productive to me.

2.11
	why not simply use "text/xcal" ? 

	again, why the restriction for backwards compatability? This
sounds like you are enforcing client functionality. How about you allow
the MTA or client application to determine whether or not to send a
downlevel representation?

2.12
	how about using a double extension - <filename>.xml.xcs
	This is reminiscent of tar files for those who are ancient
enough to remember those - anytime to add another layer of
schematization over a file, you add an extension.  Why don't we follow
the same pattern? I can't think of a good reason not to.

	While you're at it - why not go another step further and specify
file extensions for the different types of iCals (which the ical
standard unfortunately failed to do) - for instance, a meeting request
"method='request'" might have an extension of .xrc while a published
calendar "method='publish'" might have an extension of .xcs - this gives
everyone a much more tangible understanding of the data without having
to crack it and parse it first. There's a thought.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Aug 2005 16:29:07 +0200

Dan Connolly wrote:
> On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote:
> [...]
> 
>>>Copies of the draft at:
>>>
>>"http://ietf.org/rfc/rfcXXXX.txt" as namespace name;
> 
> 
> Right; I gather Best Current Practice is...
> 
> [[[
> If the registrant wishes to
>    have a URI assigned, then a URN of the form
> 
>       urn:ietf:params:xml:<class>:<id>
> 
>    will be assigned where <class> is the type of the document being
>    registered (see below).
> ]]]
>  -- http://www.faqs.org/rfcs/rfc3688.html

One could probably also use: <urn:ietf:rfc:NNNN> (see 
<http://ietf.org/rfc/rfc2648>).

> ...

Best regards, Julian

---

From: Doug Royer <[email-masked]>
Date: Tue, 09 Aug 2005 14:52:43 -0600

> element is in no namespace?

I think we need to have it in a namespace.
I can go ether way.

I think we need to define one so that mixed content can
exist in an XML file.

> probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead.

:-)

--

---

From: Tim Hare <[email-masked]>
Date: Tue, 09 Aug 2005 22:29:26 -0400

Actually, if I recall my XML rules, you can code:

<xCal:iCalendar
xmlns:xCal="http://ietf.org/rfc/rfcXXXX.txt">

Namespaces apply to the containing element as well. And I agree
that the iCalendar element should be in a namespace. Just for
human-readability reasons it associates the iCalendar with the xCal
namespace, and that's a good thing to be reminded ot.

At 04:52 PM 8/9/2005, Doug Royer wrote:

Julian Reschke wrote:

I can go ether way.

exist in an XML file.

2) I don't think the IETF will
let you use something like
"
http://ietf.org/rfc/rfcXXXX.txt" as namespace name; but if they
do, you probably should use
"
http://ietf.org/rfc/rfcXXXX" (no extension)
instead.

:-)

--

Doug
Royer
|

http://INET-Consulting.com

Tim Hare

Interested Bystander, Non-Inc.