[Ietf-calsify] Re: [Ietf-caldav] xCal - resubmitted.

Joe Hildebrand hildjj at gmail.com
Tue Sep 20 23:26:52 PDT 2005


On namespace URIs: We went through this on XMPP.  It turned out that
URIs of this form were the winner:

urn:ietf:params:xml:ns:xmpp-tls
urn:ietf:params:xml:ns:xmpp-sasl

(See RFC 3920)

I also agree that <iCalendar/> needs to be in a namespace.  I'm not
sure why it needs to be in a different namespace than <vcalendar/>,
unless you wanted to be able to put other things inside a calendar. 
I'd suggest that having two different namespaces would be unnecessary
complexity.

>From 2.7, xmlns isn't really an attribute.  You shouldn't call out how
namespaces work.  And PLEASE don't imply that prefixes are required,
or that they must take on some special value.  I want to be able to
use a doc like this:

<iCalendar xmlns='urn:ietf:params:xml:ns:xcal'>
  <vcalendar>
    <version>2.0</version>
  </vcalendar>
</iCalendar>

which is semantically identical (assuming that iCalendar moves into
the namespace).  Writing your examples in this format might make them
easier to read, as well.

If the language attribute could be mapped (special-case) on to
xml:lang, it would be great, since there are some tools that already
deal with xml:lang.

In 2.9, specifying that invalid XML characters MUST be entity encoded
prohibits <![CDATA[ ]]> escapes.   You might just refer to standard
XML escaping mechanisms.

I don't think 2.10 adds value.  People using XML should understand
[XMLNS] at this point.  No need to be remedial.

It might be nice to have a section about extensibility.
- extend with any XML you want, as long as it's in its own namespace
- MUST ignore any extensions you don't understand
- MUST NOT expect extensions to survive round-tripping to ical.

Once some of the namspace issues are worked out, it looks like you're
on the right track.

On 8/9/05, Julian Reschke <julian.reschke at gmx.de> wrote:
> Dan Connolly wrote:
> > On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote:
> > [...]
> >
> >>>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
> >>
> >>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;
> >
> >
> > 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
> _______________________________________________
> Ietf-caldav mailing list -- Ietf-caldav at osafoundation.org
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
> 


-- 
Joe Hildebrand


More information about the Ietf-calsify mailing list