[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: I-D ACTION:draft-pessi-ical-isip-01.txt]
Doug Royer <Doug@xxxxxxxxx> writes:
>I just noticed this e-mail on the IETF-general list.
I first received an automatic rejection reply, so I thought I'll
have to send it again after cutoff period. Christmas seems to
come twice this year.
The document now recommends using the "text/calendar" format,
and the examples have been converted to the iCal.
There are a few open issues, most important I think is
*what to do when a recipient cannot be reached immediately?*
If delivery falls back to some other system than SIP, e.g.,
e-mail, what kind of addressing could be used? How a recipient
can process and an iSIP message if it is received via non-SIP
There is no applicability statement in the draft. Our main
purpose here is to have off-line invitations to SIP conferences
with standard format describing attendees and resources of SIP
Unfortunately I've had no opportunity to dig in iRIP, so I
really can't say for sure what makes iSIP radically different
from iRIP. In my opinion, iSIP is just an alternative transport
for iTIP with its own addresses. SIP is an existing transport,
which propably will live and prosper on its own. iSIP is useful
even if there is no real calendaring system available by SIP
user-agents. It also helps to integrate the calendar and
telephone applications in future mobile phones and PDAs.
>-------- Original Message --------
>Subject: I-D ACTION:draft-pessi-ical-isip-01.txt
>Date: Tue, 11 Mar 2003 06:46:22 -0500
>To: IETF-Announce: ;
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> Title : iCalendar SIP-Based Interoperability Protocol
> Author(s) : P. Pessi, M. Mela
> Filename : draft-pessi-ical-isip-01.txt
> Pages : 13
> Date : 2003-3-10
>This document, proposes a binding from the abstract iCalendar
>Transport-independent Interoperability Protocol (iTIP) using Session
>Initiation Protocol (SIP) as transport and SIP/SIPS URIs as
>addresses. This document proposes using the iTIP objects as a MIME
>payload format with SIP. iTIP is an abstract transport protocol for
>exchanging calendaring information between calendar systems using the
>iCalendar, Internet Calendaring and Scheduling Core Object
>Specification defined by RFC 2445. SIP is a application-layer
>signaling protocol for creating, modifying, and terminating
>multimedia sessions, retrieving user presence and sending instant
>A URL for this Internet-Draft is:
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
> "get draft-pessi-ical-isip-01.txt".
>A list of Internet-Drafts directories can be found in
>Internet-Drafts can also be obtained by e-mail.
>Send a message to:
>In the body type:
> "FILE /internet-drafts/draft-pessi-ical-isip-01.txt".
>NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the