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

[Cameron Stillion]

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:helge.hess at opengroupware.org] 
Sent: Tuesday, August 09, 2005 9:54 AM
To: Cameron Stillion
Cc: Calsify; CalDAV DevList
Subject: Re: [Ietf-caldav] xCal - resubmitted.

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

On 9. Aug 2005, at 18:12 Uhr, Cameron Stillion wrote:
> (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...)

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

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
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org