Re: [caldav] SCHEDULE-STATUS inconsistencies and questions

Arnaud Quillaud <Arnaud.Quillaud@Sun.COM> Thu, 19 November 2009 10:10 UTC

Return-Path: <Arnaud.Quillaud@Sun.COM>
X-Original-To: caldav@core3.amsl.com
Delivered-To: caldav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169423A6A78 for <caldav@core3.amsl.com>; Thu, 19 Nov 2009 02:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuNf6VxnJBHZ for <caldav@core3.amsl.com>; Thu, 19 Nov 2009 02:10:40 -0800 (PST)
Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id 5191D3A6A57 for <caldav@ietf.org>; Thu, 19 Nov 2009 02:10:40 -0800 (PST)
Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAJAAatN007864 for <caldav@ietf.org>; Thu, 19 Nov 2009 10:10:36 GMT
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; CHARSET="US-ASCII"; format="flowed"
Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTC00800PAYNZ00@fe-emea-09.sun.com> for caldav@ietf.org; Thu, 19 Nov 2009 10:10:34 +0000 (GMT)
Received: from vpn-129-150-116-96.uk.sun.com ([unknown] [129.150.116.96]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTC00H21PLGGK70@fe-emea-09.sun.com> for caldav@ietf.org; Thu, 19 Nov 2009 10:10:28 +0000 (GMT)
Date: Thu, 19 Nov 2009 11:10:30 +0100
From: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>
In-reply-to: <4B0514C5.5030902@sun.com>
Sender: Arnaud.Quillaud@Sun.COM
To: caldav@ietf.org
Message-id: <4B051996.6050902@sun.com>
References: <4B0514C5.5030902@sun.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4
Subject: Re: [caldav] SCHEDULE-STATUS inconsistencies and questions
X-BeenThere: caldav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <caldav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/caldav>
List-Post: <mailto:caldav@ietf.org>
List-Help: <mailto:caldav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2009 10:10:42 -0000

OK. Should have read the table more carefully: it looks like a lack of 
schedule-deliver-invite or schedule-deliver-reply privilege would 
actually result in a 5.3: " The scheduling message was not delivered and 
was rejected because scheduling with that recipient is not allowed. This 
is likely a permanent failure, and the originator should not try to send 
the message again."

If it is the case, does 3.8 correspond to the lack of " schedule-send" 
privilege ? I would have expected a needs-privilege error when doing the 
PUT when lacking such privilege. Or does it correspond to something else ?

Thanks,

Arnaud Quillaud


On 11/19/09 10:49 AM, Arnaud Quillaud wrote:
> Hello,
>
> I noticed some inconsistencies between the definition and the examples 
> regarding the SCHEDULE-STATUS parameter:
>
> While the definition states that only the status code (e.g. "2.1") 
> should be present, all the examples include both the status code and 
> status description (e.g. "1.2;Scheduling message has been delivered").
>
> Then a question: the list of valid status for delivery at 
> http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-08#section-9.2 
> includes
>
> 3.8 " The scheduling message was not delivered due to insufficient 
> privileges."
>
> I assumed that this would happen in the case where the organizer does 
> not have schedule-deliver-invite privilege, or if the attendee 
> replying does not have schedule-deliver-reply.
>
> On the other hand, iTIP describes 3.8 
> (http://tools.ietf.org/html/draft-ietf-calsify-2446bis-10#section-3.6.21) 
> as meaning that " iTIP operation failed because an **Attendee** does 
> not have suitable privileges for the operation."
>
> When would this happen ?
>
> Thanks,
>
> Arnaud Quillaud