
Message-ID: <471EA94D.8050603@oracle.com>
Date: Tue, 23 Oct 2007 22:09:17 -0400
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: CalDAV DevList <ietf-caldav@osafoundation.org>
Content-Type: multipart/mixed; boundary="------------020806050008070402060909"
Subject: [Ietf-caldav] [Fwd: RFC 5051 on i; unicode-casemap - Simple Unicode Collation Algorithm]
Precedence: list

This is a multi-part message in MIME format.
--------------020806050008070402060909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

FYI

-------- Original Message --------
Subject: RFC 5051 on i;unicode-casemap - Simple Unicode Collation Algorithm
Date: Tue, 23 Oct 2007 17:20:02 -0700 (PDT)
From: rfc-editor@rfc-editor.org
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: rfc-editor@rfc-editor.org


A new Request for Comments is now available in online RFC libraries.


         RFC 5051

         Title:      i;unicode-casemap - Simple Unicode Collation
                     Algorithm
         Author:     M. Crispin
         Status:     Standards Track
         Date:       October 2007
         Mailbox:    MRC@CAC.Washington.EDU
         Pages:      7
         Characters: 14965
         Updates/Obsoletes/SeeAlso:   None

         I-D Tag:    draft-crispin-collation-unicasemap-07.txt

         URL:        http://www.rfc-editor.org/rfc/rfc5051.txt

This document describes "i;unicode-casemap", a simple
case-insensitive collation for Unicode strings.  It provides
equality, substring, and ordering operations.  [STANDARDS TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.Please refer to the current edition of the Internet
  Official Protocol Standards (STD 1) for the standardization state and
  status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body

help: ways_to_get_rfcs. For example:

         To: rfc-info@RFC-EDITOR.ORG
         Subject: getting rfcs

         help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce


--------------020806050008070402060909
Content-Type: text/x-vcard; charset=utf-8;
 name="bernard.desruisseaux.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="bernard.desruisseaux.vcf"

begin:vcard
fn:Bernard Desruisseaux
n:Desruisseaux;Bernard
email;internet:bernard.desruisseaux@oracle.com
version:2.1
end:vcard


--------------020806050008070402060909--


Return-Path: <bernard.desruisseaux@oracle.com>
X-Original-To: ietf-caldav@osafoundation.org
Delivered-To: ietf-caldav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6C38380A2C; Wed,  3 Oct 2007 10:45:32 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8B272142217; Wed,  3 Oct 2007 10:44:37 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.26
X-Spam-Level: 
X-Spam-Status: No, score=-2.26 tagged_above=-50 required=4 tests=[AWL=0.338, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRTxlkAh1JYV; Wed,  3 Oct 2007 10:44:31 -0700 (PDT)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 045F1142213; Wed,  3 Oct 2007 10:44:30 -0700 (PDT)
Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l93HiS8M004561; Wed, 3 Oct 2007 12:44:28 -0500
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l93FmWo8006240; Wed, 3 Oct 2007 11:44:27 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt351.oracle.com with ESMTP id 3264528431191432281; Wed, 03 Oct 2007 10:24:41 -0700
Received: from [10.156.42.83] (/10.156.42.83) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Oct 2007 10:24:41 -0700
Message-ID: <4703D056.6020403@oracle.com>
Date: Wed, 03 Oct 2007 13:24:38 -0400
From: Bernard Desruisseaux <bernard.desruisseaux@oracle.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Arnaud Quillaud <Arnaud.Quillaud@sun.com>
References: <0JPA004H0EWVZ280@fe-emea-10.sun.com>
In-Reply-To: <0JPA004H0EWVZ280@fe-emea-10.sun.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
Cc: Calsify <Ietf-calsify@osafoundation.org>, CalDAV DevList <ietf-caldav@osafoundation.org>
Subject: [Ietf-caldav] Re: RE : [Ietf-calsify] iTIP: persisting SEQUENCE number
X-BeenThere: ietf-caldav@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:ietf-caldav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-caldav>
List-Post: <mailto:ietf-caldav@osafoundation.org>
List-Help: <mailto:ietf-caldav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>,  <mailto:ietf-caldav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Oct 2007 17:45:32 -0000

Hi Arnaud,

Arnaud Quillaud wrote:
> 
> Cyrus Daboo wrote:
 >
>> Again, my feeling on this is as follows: iTIP makes it clear that the 
>> ORGANIZER'S CUA has to persist on a per-ATTENDEE basis, the 
>> SEQUENCE/DTSTAMP values (section 2.1.5). What is important is 
>> that the CUA 
>> track what the next expected SEQUENCE/DTSTAMP reply for any 
>> one attendee is 
>> going to be.
>>
> 
> In the case of a CalDAV based CUA, how is the client supposed to persist
> this per ATTENDEE SEQUENCE information on the server (e.g. in the case
> where the organizer is using 2 cal clients) ? If CalDAV scheduling is
> used, the CUA may try to guess the right SEQUENCE by looking at the
> outbox history but that is not guaranteed to work as servers are not
> required to keep the outbox history.

Currently, the CalDAV calendar-schedule draft only defines two new
iCalendar parameters RECEIVED-SEQUENCE and RECEIVED-DTSTAMP to
"persist" the value of the SEQUENCE and DTSTAMP properties that was
specified in the most recent reply received from a given Attendee.
Example:

   ATTENDEE;CN="Cyrus Daboo";PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE=2;
    RECEIVED-DTSTAMP=20070214T123456Z:mailto:cyrus@example.com

The purpose of these parameters is only to allow the handling of
scheduling messages that arrive in an unexpected order (i.e., not
at all what you are asking for)

We are still debating whether there is a need for the Organizer to
"persist" on a per Attendee basis the last SEQUENCE number sent to
the Attendee.

I believe we need to answer the following questions:

1- Is there a use case where the Organizer bumps the SEQUENCE
    number but doesn't send an update to any Attendee?

2- Is there a use case where the Organizer bumps the SEQUENCE
    number and only sends an update to some Attendees?

    [ The case of an Organizer adding new Attendees and only
      sending an update to those new Attendees would be an
      example *if* the Organizer (his CUA really) also bump
      the SEQUENCE number.  According to iCalendar (though
      it should be "according to iTIP") the Organizer is not
      required to bump the SEQUENCE number here. If the
      SEQUENCE number is bumped, I would say that all the
      Attendees should receive an update... ]

3- Is there a use case where the Organizer would consider
    an Attendee reply that specifies a SEQUENCE number less
    than the current SEQUENCE number?

Cheers,
Bernard