Subject: [Ietf-calsify] Re: [issue21] do we need a new mime type for this update, in order for backward compat?

From: lear at cisco.com (Eliot Lear)
Date: Fri Jul 14 20:39:17 2006

Alexey Melnikov wrote:
> Eliot Lear wrote:
>
>> New submission from Eliot Lear <[email-masked]>:
>>
>> if we've preserved backward compat then we don't need this. 
>> otherwise we might.
>>  
>>
> I thought rfc2445bis took care of this (it registers the MIME type,
> used by iTIP and iMIP)?
>
I know it does currently, and perhaps I've misplaced the issue, but it
seemed more natural for iMIP.  This issue is a placeholder.  If we make
incompatible or substantial changes by the time we're done, we should
think about how this could be managed by calendar systems.  One approach
is to use mime multipart/alternative with a new version.  Another
approach would be to bump the iCal version number.  This is not
something we can decide until we're a little further down the road, but
we should consider it.

Eliot

---

From: TimHare at comcast.net (Tim Hare)
Date: Sat Jul 15 07:48:03 2006

I don't know about the version number - in my experimentation with some
different implementations, some of them seem to ignore the VERSION:
component entirely; if the MIME type is text/calendar or the file extension
is ".ics" they read the file as though it were "VERSION: 2.0" even if the
VERSION: component is "1.0".

I agree with the statement "if we've preserved backward compat then we don't
need this".  I believe one of the original goals of Calsify was to reach a
sort of "least common denominator" that could be used without breaking
existing implementations badly enough to cause major redevelopment efforts.
I still think that's a good idea, and so would not like to see incompatible
or substantial changes. 

In my opinion, if you change things significantly enough to cause those
kinds of problems, you might as well go ahead and change over to an
XML-based syntax while you're at it: at least with XML you could fairly
easily invoke a parser and stylesheet in your input pipeline to transform it
into whatever your implementation understands.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: Friday, July 14, 2006 11:39 PM
To: Alexey Melnikov
Cc: [email-masked]
Subject: [Ietf-calsify] Re: [issue21] do we need a new mime type for this
update, in order for backward compat?

I know it does currently, and perhaps I've misplaced the issue, but it
seemed more natural for iMIP.  This issue is a placeholder.  If we make
incompatible or substantial changes by the time we're done, we should think
about how this could be managed by calendar systems.  One approach is to use
mime multipart/alternative with a new version.  Another approach would be to
bump the iCal version number.  This is not something we can decide until
we're a little further down the road, but we should consider it.

Eliot
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify