Subject: [Ietf-calsify] xCal - resubmitted.

From: Doug at royer.com (Doug Royer)
Date: Mon Aug 8 13:44:19 2005

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Doug.vcf
Type: text/x-vcard
Size: 373 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050808/0db0265a/Doug.vcf

---

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Aug 9 02:50:36 2005

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: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Tue Aug 9 03:22:47 2005

On Tuesday 09 August 2005 11:35, Cameron Stillion wrote:
> enough to remember those 

Sorry, but just because tar archives are not common under Windows, doesn't 
mean they are ancient. In fact, they are the most common compressed archive 
format in Linux and also on Unix systems, far more popular than zip files! 
E.g. almost all source code for Linux applications (if not accessed through 
svn, cvs or some other versioning system) is distributed as gzipped tar files 
or bziped tar files. 

> - anytime to add another layer of 

File names (and thus also the part after a period in the file name) in Linux 
don't really have such a strong binding to the file type than the file name 
extensions in Windows. 

> to crack it and parse it first. There's a thought.

As I said, in Linux and unix systems, the file name extension is typically not 
associated with the file content as strong as Windows uses them. Sure, they 
can be used to indicate the type of a file, but that's noting more than an 
indication and doesn't mean it really has to be that type of file. There are 
better means of determining the contents of a file in Linux.

Cheers,
Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050809/c0df5607/attachment-0001.pgp

---

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Aug 9 03:59:13 2005

I'm glad there are others who remember such tools.

Surely there are more stringent mechanisms than looking at the file
extension - this is simply the first hint.  This is the reason that file
extensions were invented, to give the first hint as to what to do with
the file.  It treats the file as an object, and lends the file system an
object-oriented nature.  Applications, verbs, or actions can be
associated with extensions or schemes, or both.  

Granted, it is not the last word.  I can rename a text file with .exe or
.tar, but in unix or windows or osx, this does not mean it will
execute... And this approach is not specific to any particular OS, to be
sure.

The idea here is to give processing software an idea what is inside the
envelope.  If you are familiar with the envelope/letter approach to data
abstraction, it is a very powerful metaphor.  This proposal mentions
that it will NOT use .xml as an extensions - presumably for this same
reason.  If all applications, MTAs, and processing software of all
operating systems begin to name data files based on the use of xml,
pretty soon all documents will have the .xml extension. Great.  We might
as well call everything data.xml, and go ahead with a full parse of the
content to determine what to do next.  The performance implications of
this are rather dismal, and the design I find not very useful.  Why NOT
give a hint as to the content using an extension? 

I do not know how a more simple and direct way of giving a hint to the
processing software might be, than to annotate the name of the content -
but I am always willing to learn.  What are these "better ways" you
speak of? 

Cameron

-----Original Message-----
From: Reinhold Kainhofer [mailto:[email-masked]] 
Sent: Tuesday.09.August.2005 03.23
To: Cameron Stillion
Cc: Calsify; CalDAV DevList
Subject: Re: [Ietf-caldav] xCal - resubmitted.

> 	This is reminiscent of tar files for those who are ancient
enough to 
> remember those

Sorry, but just because tar archives are not common under Windows,
doesn't mean they are ancient. In fact, they are the most common
compressed archive format in Linux and also on Unix systems, far more
popular than zip files! 
E.g. almost all source code for Linux applications (if not accessed
through svn, cvs or some other versioning system) is distributed as
gzipped tar files or bziped tar files. 

> the same pattern? I can't think of a good reason not to.

File names (and thus also the part after a period in the file name) in
Linux don't really have such a strong binding to the file type than the
file name extensions in Windows. 

> 	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 
> 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.

As I said, in Linux and unix systems, the file name extension is
typically not associated with the file content as strong as Windows uses
them. Sure, they can be used to indicate the type of a file, but that's
noting more than an indication and doesn't mean it really has to be that
type of file. There are better means of determining the contents of a
file in Linux.

Cheers,
Reinhold
--
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien,
http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Tue Aug 9 04:19:12 2005

> give a hint as to the content using an extension?

While I agree with all of that, I honestly think that it doesn't belong 
into a specification on the xCal data format.

Standardizing content typing is a completely different story and 
actually one which is already covered and widely implemented in RFCs: 
MIME. This is used for both, transmitting iCal/xCal by mail and for 
storing iCal/xCal content in HTTP servers.
How MIME is mapped to local storages (extensions, resource forks, FS 
annotations, spotlight attributes etc) is entirely operating system 
dependend.

So in my opinion you might want to document a file-extension "best 
practice" for xCal, but it doesn't really belong into the RFC. The RFC 
should just outline the MIME type.

> but I am always willing to learn.  What are these "better ways" you

Well, annotating the content instead of the name? Googling for MacOS 
resource forks might be a starting point to find out why file 
extensions are problematic ;-)

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: connolly at w3.org (Dan Connolly)
Date: Tue Aug 9 07:25:22 2005

On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote:
[...]
> 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

Meanwhile, you can get an http namespace name from W3C if you like:

"W3C provides the service of allocating and maintaining persistent URIs
so that those URIs remain stable during discussions. Allocation does not
imply any endorsement by W3C of the related specifications."
 -- http://www.w3.org/1999/10/nsuri

see for example http://www.w3.org/2005/Atom

>  but if they do, you 
> probably should use "http://ietf.org/rfc/rfcXXXX" (no extension) instead.

Actually I think the .txt form is more official:

[[
The full
   text of the specification is then available using the following URL:

      http://www.ietf.org/rfc/rfcNNNN.txt

   where "NNNN" is the number of the RFC being submitted.
]]
 -- section 3.4.2 Submitting IETF Documents to JTC1
http://www.ietf.org/rfc/rfc3563.txt

The /rfc/rfcXXXX form is supported by accident, as far as I can tell.

> Best regards, Julian

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

---

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Aug 9 09:12:19 2005

Not instead of - just in addition to. It's just a hint.  Windows also
has "forested" files, and "structured" files, just like Mac's "resource
forks". I agree you'd never want to use a filename INSTEAD of the actual
annotations internally.  But philosophically, why not put "publisher's
clearinghouse sweepstakes" on the OUTSIDE of the envelope as well? 

Perhaps it doesn't belong in this particular document, though it seems
many format documents have trouble avoiding it.  If we speak of
attachments, we're going to have to pick something to use in our
examples.

Design sneaks into implementation...

(interestingly enough, it seems MacOS is now, in many cases, favoring
file extensions and "all the data in the 'data fork'" rather than using
separate resource forks.  Fascinating...)

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Helge Hess
Sent: Tuesday.09.August.2005 04.20
To: Cameron Stillion
Cc: Calsify; CalDAV DevList
Subject: Re: [Ietf-caldav] xCal - resubmitted.

On Aug 9, 2005, at 12:59, Cameron Stillion wrote:
> The idea here is to give processing software an idea what is inside 
> the envelope.  If you are familiar with the envelope/letter approach 
> to data abstraction, it is a very powerful metaphor.  This proposal 
> mentions that it will NOT use .xml as an extensions - presumably for 
> this same reason.  If all applications, MTAs, and processing software 
> of all operating systems begin to name data files based on the use of 
> xml, pretty soon all documents will have the .xml extension. Great.  
> We might as well call everything data.xml, and go ahead with a full 
> parse of the content to determine what to do next.  The performance 
> implications of this are rather dismal, and the design I find not very

> useful.  Why NOT give a hint as to the content using an extension?

Well, annotating the content instead of the name? Googling for MacOS
resource forks might be a starting point to find out why file extensions
are problematic ;-)

Greets,
   Helge

_______________________________________________
Ietf-caldav mailing list -- [email-masked] See
http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Tue Aug 9 09:54:43 2005

now thats getting entirely off-topic, but anwyay ...

> separate resource forks.  Fascinating...)

Its that way for a long time (~4 years?), since NeXTstep 5 aka MacOSX.

If you are interested on the topic:
   http://arstechnica.com/reviews/os/macosx-10.4.ars/11

> But philosophically, why not put "publisher's

You can, but you started to discuss clever ways of file extension  
mapping which is not used that way anywhere (except for informational  
purposes). This is IMHO out of scope of the RFC, better avoid the  
whole issue.

BTW: the example of "file.xml.xcal" is _not_ the same thing like  
"file.tar.gz". The latter forms no typing hierarchy but a stacking of  
formats (converting a .gz will result in a .tar, its not a special  
type or "subclass" of .tar). BTW2: Few systems support such stacking  
which is why .tgz is not so unusual either.

> If we speak of attachments, we're going to have to pick something  
> to use in our
> examples.

I don't see how this would matter for the xCal spec. It describes the  
data format, not the transport and therefore doesn't include any  
filenames (with or without extensions).
Do I miss something?

Greets,
   Helge

---

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Aug 9 11:37:49 2005

I appreciate your point Helge - still, the standard can scarcely avoid
using a filename (see attachments section) and actually, this seems like
a very simple and meaningful place to provide interoperability
guidelines. Most other "file format" standards cannot avoid it, or
choose instead to specify it. That's probably why it's here in the first
place.

Are you suggesting we remove all references to filenames/extensions from
this draft? And in general, would you say we should not suggest anything
outside the internals of the MIME type itself?  
In practice, I find this incomplete - but if you think it belongs
elsewhere, that's fine.

REBTW1: the distinction between an encapsulated format and a
specialization of a format is a fine one.  I rather think extensions are
useful hints, not strictly delineations of encapsulation or (indeed) of
specialization.  But the similarities here are useful. I understand your
concern, but the purpose is merely informational, not a strict
non-repudiation of format, encoding, or schema.

REBTW2: Extension "stacking" is not "unsupported" by most systems
either. It works fine in Unix, Mac, and Windows. 

Anyway, is there anyone else who feels as I do that enforcing both xcal
and ical as multipart alternative is overkill?  Or is this also beyond
the scope of this proposal?

-----Original Message-----
From: Helge Hess [mailto:[email-masked]] 
Sent: Tuesday, August 09, 2005 9:54 AM
To: Cameron Stillion
Cc: Calsify; CalDAV DevList
Subject: Re: [Ietf-caldav] xCal - resubmitted.

On 9. Aug 2005, at 18:12 Uhr, Cameron Stillion wrote:
> file extensions and "all the data in the 'data fork'" rather than 
> using separate resource forks.  Fascinating...)

> But philosophically, why not put "publisher's clearinghouse 
> sweepstakes" on the OUTSIDE of the envelope as well?

You can, but you started to discuss clever ways of file extension
mapping which is not used that way anywhere (except for informational
purposes). This is IMHO out of scope of the RFC, better avoid the whole
issue.

BTW: the example of "file.xml.xcal" is _not_ the same thing like
"file.tar.gz". The latter forms no typing hierarchy but a stacking of
formats (converting a .gz will result in a .tar, its not a special type
or "subclass" of .tar). BTW2: Few systems support such stacking which is
why .tgz is not so unusual either.

> If we speak of attachments, we're going to have to pick something to 
> use in our examples.

Greets,
   Helge

---

From: Doug at royer.com (Doug Royer)
Date: Tue Aug 9 13:18:46 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050809/57c0f9a3/smime.bin

---

From: Doug at royer.com (Doug Royer)
Date: Tue Aug 9 13:47:20 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050809/c0952ac1/smime-0001.bin

---

From: Doug at royer.com (Doug Royer)
Date: Tue Aug 9 13:52:52 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050809/041208e8/smime.bin

---

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Aug 9 17:59:43 2005

The multiple dots have no ill effects to users of Windows versions that
support long filenames (XP, 2000, and perhaps 98, though to a limited
degree) - only the final dot extension is meaningful when associating
application behaviors or displaying icons, etc. The rest of the string
is considered the filename sans extension. Like the .tar example, this
leaves further "unwrapping" of the file up to the application.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Tuesday, August 09, 2005 1:47 PM
To: [email-masked]
Cc: Calsify; CalDAV DevList; [email-masked]
Subject: [Ietf-caldav] Re: xCal - resubmitted - file name suffix

[ I have set the REPLY-TO to the [email-masked] mailing
   list - This is of interest to CALSIFY and CALDAV users, but not
   really 'on topic' - Join at
   http://inet-consulting.com/mailman/listinfo/xcal ]

As to the file name suffix point . Many insisted (Mostly Microsoft and
Microsoft application developers) that iCal define a file extension.

And as I have noticed that MANY implementations store ICS files without
their text/calendar MIME header. I suspect many will for xCAL. So
without a MIME type in the file, many data typing engines would fail if
it were not for a file name suffix.

So xCal has a file extension. I do not care what it is.
And I do not care how many 'dots' are in the file name as long as the
OS's and their applications allow for it.

> either. It works fine in Unix, Mac, and Windows.

It is supported by some POSIX (UNIX, Linux, BSD, and newer
Mac) applications, but not those OS's.

In fact on those POSIX OS's the 'dot' means nothing at all and it is
simply another character in the file name that can have zero to many
'dot's in the file name.

Cameron - Question: Can the windows registry handle multiple DOTs in
suffixes to files on what ever are the top most Windows versions in use?

My VERY LIMITED knowledge and testing says no, but I might not know what
I am doing as I use POSIX systems for almost everything.

--

---

From: TimHare at comcast.net (Tim Hare)
Date: Tue Aug 9 20:08:46 2005

An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050809/945145fd/attachment.html

---

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Aug 12 16:00:21 2005

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: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Aug 12 16:00:21 2005

>  -- 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