[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: I-D ACTION:draft-pessi-ical-isip-01.txt]



	Sorry for the delay, but I have had problems getting the
	sendmail smarthost pointing to the right server... 

"pregen@xxxxxxxxxxxxxxxxxx" <pregen@xxxxxxxxxxxxxxxxxx> writes:
>Hi Pekka.  The document references that it is a CALSCH working group 
>document.  We've never seen it discussed here nor is it a part of our 
>charter.  Can you fill us in a little on what this is?  

	I hope that I have made it clear in the document that it is an
	individual submission, not a CALSCH WG item. I presented the
	document in the CALSCH and SIPPING WGs during November IETF, and
	got a few comments there.

>I see why you think it is part of our WG - however, we sort of have to
>get permission from our Area Directors to add items to our charter.

	I'd like to know what is the WG opinion here. Do you feel that
	it is OK to discuss the draft here on CALSCH list, or is some
	other forum, like the mailing list of SIPPING WG more
	appropriate? Do you feel that iSIP should be a CALSCH WG item?
	(In that case, update to the WG charter and AD approval is
	required.)

	In any case I'd like to keep the iCalendar people aware of the
	progress of iSIP, so they have a chance to object loudly if it
	would cause problems to iMIP or CAP. The discussion can always
	be redirected to a more appropriate mailing list, if required.

	Best regards,
					Pekka Pessi


>        To:     "ietf-calendar@xxxxxxx" <ietf-calendar@xxxxxxx>
>        cc: 
>        Subject:        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
>                 means?

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

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

>  Pekka Pessi


>>-------- Original Message --------
>>Subject: I-D ACTION:draft-pessi-ical-isip-01.txt
>>Date: Tue, 11 Mar 2003 06:46:22 -0500
>>From: Internet-Drafts@xxxxxxxx
>>Reply-To: Internet-Drafts@xxxxxxxx
>>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
>>messages.

>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-pessi-ical-isip-01.txt

>>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
>>http://www.ietf.org/shadow.html
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


>>Internet-Drafts can also be obtained by e-mail.

>>Send a message to:
>>                mailserv@xxxxxxxxx
>>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
>>Internet-Draft.