headers
Cyrus Daboo | 7 May 2008 02:50
Favicon

RE: Issue 86

Hi Tim,
Sorry for the delay in getting back to you on this.

--On March 11, 2008 10:07:42 AM -0400 Tim Hare <TimHare <at> comcast.net> wrote:

> It seems as though we are somehow specifying how the CUA interacts with
> the user (whether to be notified or not, etcetera).  This, to me, does not
> belong in iTIP .  iTIP should be solely about the exchange of calendaring
> information between two calendaring tools; adding CUA<->user interaction
> is really outside the scope of iTIP. As such, it adds un-needed
> complexity to the document which doesn't advance the goals of
> simplification and interoperability.

So there was some discussion of this at the IETF meeting, and I think most 
people there were not worried by this.

I think iTIP is about the exchange and processing of scheduling messages 
and I think guidance on how to handle SEQUENCE changes is relevant. That 
said I think the proposed text can be "toned down" a little bit by not 
talking about calendar users in a direct manner:

    Whilst a change in SEQUENCE number is indicative of a significant
    change to a previously scheduled item, ATTENDEE CUAs SHOULD NOT rely
    solely on a change in SEQUENCE as a means of detecting a significant
    change. Instead CUAs SHOULD compare the old and new versions of the
    calendar components and determine the exact nature of the changes and
    make decisions, possibly based on calendar user preferences, as to
    whether the user needs to be explicitly informed of the change.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 7 May 2008 03:42
Favicon

RE: Issue 95: text on REQUEST-STATUS

Hi Tim,

--On March 11, 2008 10:10:40 AM -0400 Tim Hare <TimHare <at> comcast.net> wrote:

>  "Additional codes MAY be used provided it is known that the recipient's
> CUA has appropriate knowledge of such codes."
>
> This is not a good thing for interoperability. CUA-specific status codes
> need to be an X- component (ex: X-MYCAL-REQUEST-STATUS). The only way one
> end can know for certain the other end "has appropriate knowledge of such
> codes" is if both are from the same vendor.
>

The alternative is to create a registry of status codes. I am not thrilled 
by that prospect but it is the best thing for interoperability. I also 
think that there are likely to be iTIP based protocols that will need their 
own specific codes (e.g. there is some useful status in CalDAV scheduling 
that could be conveyed in new codes).

Anyone else think the status codes should be in a registry.

--

-- 
Cyrus Daboo
Permalink | Reply | 1 comment |
headers
Tim Hare | 7 May 2008 04:55
Picon

RE: Issue 95: text on REQUEST-STATUS

I don't have a strong opinon about a registry, not having a lot of
experience with them; my point is that only those codes which are defined in
the document should be used in a non X- component.  That could be done by
enumerating those interoperable codes in the RFC document, I suppose
although the registry has the advantage of allow us to include new codes 'by
reference' rather than having to revise the RFC again. 

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: Cyrus Daboo [mailto:cyrus <at> daboo.name] 
Sent: Tuesday, May 06, 2008 9:42 PM
To: Tim Hare; ietf-calsify <at> osafoundation.org
Subject: RE: [Ietf-calsify] Issue 95: text on REQUEST-STATUS

Hi Tim,

--On March 11, 2008 10:10:40 AM -0400 Tim Hare <TimHare <at> comcast.net> wrote:

>  "Additional codes MAY be used provided it is known that the 
> recipient's CUA has appropriate knowledge of such codes."
>
> This is not a good thing for interoperability. CUA-specific status 
> codes need to be an X- component (ex: X-MYCAL-REQUEST-STATUS). The 
> only way one end can know for certain the other end "has appropriate 
> knowledge of such codes" is if both are from the same vendor.
>

The alternative is to create a registry of status codes. I am not thrilled
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyrus Daboo | 7 May 2008 05:26
Favicon

RE: Issue 95: text on REQUEST-STATUS

Hi Tim,

--On May 6, 2008 10:55:26 PM -0400 Tim Hare <TimHare <at> comcast.net> wrote:

> I don't have a strong opinon about a registry, not having a lot of
> experience with them; my point is that only those codes which are defined
> in the document should be used in a non X- component.  That could be done
> by enumerating those interoperable codes in the RFC document, I suppose
> although the registry has the advantage of allow us to include new codes
> 'by reference' rather than having to revise the RFC again.
>

Well we could just say that new codes must be defined in a standards track 
RFC. That way other specs can add there own and review of those can ensure 
there are no clashes

--

-- 
Cyrus Daboo
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 12 May 2008 05:15
Picon
Favicon

I-D Action:draft-ietf-calsify-2446bis-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title           : iCalendar Transport-Independent Interoperability Protocol (iTIP)
	Author(s)       : C. Daboo
	Filename        : draft-ietf-calsify-2446bis-06.txt
	Pages           : 124
	Date            : 2008-05-11

This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between
different calendar systems.  This is done without reference to a
specific transport protocol so as to allow multiple methods of
communication between systems.  Subsequent documents will define
profiles of this protocol using specific interoperable methods of
communications between systems.
iTIP complements the iCalendar object specification by adding
semantics for group scheduling methods commonly available in current
calendar systems.  These scheduling methods permit two or more
calendar systems to perform transactions such as publish, schedule,
reschedule, respond to scheduling requests, negotiation of changes or
cancel.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 12 May 2008 21:30
Picon
Favicon

I-D ACTION:draft-ietf-calsify-rfc2447bis-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Message-Based Interoperability Protocol (iMIP)
	Author(s)	: A. Melnikov
	Filename	: draft-ietf-calsify-rfc2447bis-04.txt
	Pages		: 21
	Date		: 2008-5-12
	
This document, iCalendar Message-Based Interoperability Protocol
   (iMIP), specifies a binding from the iCalendar Transport-independent
   Interoperability Protocol (iTIP) to Internet email-based transports.
Calendaring entries defined by the iCalendar Object Model (iCAL) are
   composed using constructs from RFC 2822, RFC 2045, RFC 2046,
   RFC 2047 and RFC 2049.

   This document is a product of Calendaring and Scheduling Standards
   Simplification (calsify) working group. More information about the
   IETF CALSIFY working group activities can be found on the IETF web
   site at <http://www.ietf.org/html.charters/calsify-charter.html>.

   The issue tracker for the Calsify WG is located at:
    <http://www.ofcourseimright.com/cgi-bin/roundup/calsify>

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2447bis-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eliot Lear | 13 May 2008 11:02
Picon
Favicon

RFC2446bis

Dear all,

Cyrus believes he has resolved all outstanding issues with RFC2446bis.  
I encourage everyone to read this draft, and anticipate a working group 
last call shortly.

Thanks,

Eliot
Permalink | Reply | 0 comments |
headers
Eliot Lear | 15 May 2008 15:27
Picon
Favicon

WGLC: draft-ietf-calsify-2446bis-06.txt && IETF Dublin

Dear all,

This message begins working group last call on 
draft-ietf-calsify-2446bis-06.txt.  The last call will run for one month 
and end on June 15.  Please send all comments regarding this draft to 
ietf-calsify <at> osafoundation.org.  The chairs solicit both positive 
comments and requests for change.  We ask that if possibly any requests 
for change include specific textual recommendations.

Assuming we do not get bogged down in comments, the chairs do not 
contemplate at this time a meeting in Dublin.

Thanks,

Eliot
Permalink | Reply | 1 comment |

Gmane