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

[Cameron Stillion]

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: ietf-caldav-bounces at osafoundation.org
[mailto:ietf-caldav-bounces at osafoundation.org] 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?

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.

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

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

_______________________________________________
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