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

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

[ I have set the REPLY-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 ]

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

This is left over from the CALSCH days.

When Frank, Surendra, and I did the first XCAL, we were told
by the AD's at the time that they would not endorse ANOTHER
calendar data format, unless it was an alternate view of
iCalendar data. So the agreed solution was that xCal objects
would be attached as an alternate view to iCal objects.

Currently iMIP requires that people use S/MIME. I do not recall
seeing many S/MIME iCalendar emails.

The danger here is that we re-invent the wheel breaking things.
The purpose of CALSIFY is to simplify and make a set of objects
and procedures that will enable iCal and vendors to have standard
calendaring objects. If we open up the debate to XML 'IS calendaring'
then all that is compatibility that we already have is lost.

There are many XML parsers out there and XML can be
transformed back into iCal (see my posting of the XSLT
translation on the xCal mailing list).

How do we enable XML and not disrupt iCal ?

-- 

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

               We Do Standards - You Need Standards

---

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

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

Cameron Stillion wrote:

> REBTW2: Extension "stacking" is not "unsupported" by most systems
> 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: "Cameron Stillion" <[email-masked]>
Date: Tue, 9 Aug 2005 17:59:37 -0700

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

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.

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.

--