RE: AD review issue #4: Supporting both VTODO and VEVENT in thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)

["Tim Hare" <[e-mail]>]

No disagreement from me. 


Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: Eliot Lear [mailto:[e-mail]] 
Sent: Saturday, June 28, 2008 10:19 AM
To: Tim Hare
Cc: 'Cyrus Daboo'; 'Lisa Dusseault'; [e-mail];
'Bernard Desruisseaux'
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame
iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)

I believe we have consensus as to Lisa's suggestion.  Any disagreement?

Eliot

Tim Hare wrote:
> As an "informed user" - i.e. not a developer, I definitely support 
> NON-silent rejection.  I can agree with non-support of certain 
> components only if I receive some notification;  due to work 
> requirements I am now journalling my time on some projects, and it 
> would be good to know if I can't import that data into another tool.
>
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Cyrus 
> Daboo
> Sent: Monday, June 16, 2008 12:33 PM
> To: Lisa Dusseault
> Cc: [e-mail]; Bernard Desruisseaux
> Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in 
> thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review 
> on2445bis)
>
> Hi Lisa,
>
> --On June 16, 2008 9:25:14 AM -0700 Lisa 
> Dusseault<[e-mail]>
> wrote:
>
>    
>>> The suggestion of an implementation note that describes the "common 
>>> use" of the components and explains that some may be supported and 
>>> others not is fine. In fact telling implementors that they need to 
>>> be prepared for another system to reject a component would be good.
>>>        
>> I can get behind that.  I'd also like to recommend that systems not 
>> reject a component silently -- a user needs to know if they imported 
>> a iCalendar file and lost 50 VJOURNAL components in the process.
>>      
>
> Agreed.
>
> Note that iTIP does have a status code for "Unsupported Component" 
> (3.13) - so informing the originator of the iCalendar data that they 
> are sending something that is not supported by the recipient is covered by
that.
>
> --
> Cyrus Daboo
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>    



_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1245F80D12 for <[e-mail]>; Sat, 28 Jun 2008 08:12:41 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3F4F614220E for <[e-mail]>; Sat, 28 Jun 2008 08:12:41 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.481
X-Spam-Level: 
X-Spam-Status: No, score=-1.481 tagged_above=-50 required=4 tests=[AWL=1.119,  BAYES_00=-2.599, SPF_PASS=-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 ymRvUTsYyAky for <[e-mail]>; Sat, 28 Jun 2008 08:12:30 -0700 (PDT)
Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4056514220D for <[e-mail]>; Sat, 28 Jun 2008 08:12:29 -0700 (PDT)
Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id jQxK1Z00317UAYkA905y00; Sat, 28 Jun 2008 15:12:28 +0000
Received: from THare ([71.203.105.66]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id jTC01Z0031RyUCv8ZTC8kq; Sat, 28 Jun 2008 15:12:09 +0000
X-Authority-Analysis: v=1.0 c=1 a=hX2h3j9qUEwA:10 a=n7_MfodNLFUA:10 a=PFsjAnyDAAAA:8 a=-IFHzkDpYruZAscnC7MA:9 a=U7RQsSqG44ae2_odbMUA:7 a=PgsQapws7u3gxFrMSSRbRET-CJAA:4 a=JfD0Fch1gWkA:10 a=YewFc9KQ5U8A:10 a=6-x43y6uxGMA:10
From: "Tim Hare" <[e-mail]>
To: "'Eliot Lear'" <[e-mail]>
Subject: RE: AD review issue #4: Supporting both VTODO and VEVENT in	thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review	on2445bis)
Date: Sat, 28 Jun 2008 11:12:03 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
Thread-Index: AcjZKflU9Oa+TkOQQVSSI0Xnj4q5jQABz39g
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Message-Id: <[e-mail]>
Cc: [e-mail], 'Bernard Desruisseaux' <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 28 Jun 2008 15:12:41 -0000

No disagreement from me. 


Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: Eliot Lear [mailto:[e-mail]] 
Sent: Saturday, June 28, 2008 10:19 AM
To: Tim Hare
Cc: 'Cyrus Daboo'; 'Lisa Dusseault'; [e-mail];
'Bernard Desruisseaux'
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame
iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)

I believe we have consensus as to Lisa's suggestion.  Any disagreement?

Eliot

Tim Hare wrote:
> As an "informed user" - i.e. not a developer, I definitely support 
> NON-silent rejection.  I can agree with non-support of certain 
> components only if I receive some notification;  due to work 
> requirements I am now journalling my time on some projects, and it 
> would be good to know if I can't import that data into another tool.
>
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Cyrus 
> Daboo
> Sent: Monday, June 16, 2008 12:33 PM
> To: Lisa Dusseault
> Cc: [e-mail]; Bernard Desruisseaux
> Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in 
> thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review 
> on2445bis)
>
> Hi Lisa,
>
> --On June 16, 2008 9:25:14 AM -0700 Lisa 
> Dusseault<[e-mail]>
> wrote:
>
>    
>>> The suggestion of an implementation note that describes the "common 
>>> use" of the components and explains that some may be supported and 
>>> others not is fine. In fact telling implementors that they need to 
>>> be prepared for another system to reject a component would be good.
>>>        
>> I can get behind that.  I'd also like to recommend that systems not 
>> reject a component silently -- a user needs to know if they imported 
>> a iCalendar file and lost 50 VJOURNAL components in the process.
>>      
>
> Agreed.
>
> Note that iTIP does have a status code for "Unsupported Component" 
> (3.13) - so informing the originator of the iCalendar data that they 
> are sending something that is not supported by the recipient is covered by
that.
>
> --
> Cyrus Daboo
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>    





Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8A7AA80CF9; Sat, 28 Jun 2008 07:19:35 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B8FD2142203; Sat, 28 Jun 2008 07:19:35 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -5.221
X-Spam-Level: 
X-Spam-Status: No, score=-5.221 tagged_above=-50 required=4 tests=[AWL=1.379,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-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 5Uvr51xsEQuv; Sat, 28 Jun 2008 07:19:24 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 92F6314220D; Sat, 28 Jun 2008 07:19:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,719,1204520400"; d="scan'208";a="12564154"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Jun 2008 10:19:22 -0400
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5SEJM1d012351;  Sat, 28 Jun 2008 10:19:22 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5SEJLmg000128; Sat, 28 Jun 2008 14:19:21 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Sat, 28 Jun 2008 10:19:21 -0400
Received: from elear-mac.local ([10.82.216.191]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Sat, 28 Jun 2008 10:19:21 -0400
Message-ID: <[e-mail]>
Date: Sat, 28 Jun 2008 16:19:20 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird/3.0a2pre (Macintosh; 2008062203)
MIME-Version: 1.0
To: Tim Hare <[e-mail]>
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in	thesame iCalendar stream (was: Re: [Ietf-calsify] Re: AD review	on2445bis)
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jun 2008 14:19:21.0423 (UTC) FILETIME=[F568C5F0:01C8D929]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2209; t=1214662762; x=1215526762; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20AD=20review=20issue=20#4=3A=20Supportin g=20both=20VTODO=20and=20VEVENT=20in=09thesame=0A=20iCalenda r=20stream=20(was=3A=20Re=3A=20[Ietf-calsify]=20Re=3A=20AD=2 0review=09on2445bis) |Sender:=20 |To:=20Tim=20Hare=20<[e-mail]>; bh=SJasGXr0IkLG0JnfeskAQk39kROqrPFkN/3Dv06vOMs=; b=MNbzVTxK5I+umgIA81LgH23GLyb5NhWYEQqJH5kPXdzA6frwamfE56VUJZ Vpdae+ZTExtHIePDkOYIPQLNbQEp1WRSWpElGz8tyRDxa5NAcuXVchKmbs4e EtHrXt2IY0;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
Cc: [e-mail], 'Bernard Desruisseaux' <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 28 Jun 2008 14:19:35 -0000

I believe we have consensus as to Lisa's suggestion.  Any disagreement?

Eliot

Tim Hare wrote:
> As an "informed user" - i.e. not a developer, I definitely support
> NON-silent rejection.  I can agree with non-support of certain components
> only if I receive some notification;  due to work requirements I am now
> journalling my time on some projects, and it would be good to know if I
> can't import that data into another tool.
>
>
> Tim Hare
> Interested Bystander, Non-Inc.
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Cyrus Daboo
> Sent: Monday, June 16, 2008 12:33 PM
> To: Lisa Dusseault
> Cc: [e-mail]; Bernard Desruisseaux
> Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame
> iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)
>
> Hi Lisa,
>
> --On June 16, 2008 9:25:14 AM -0700 Lisa Dusseault<[e-mail]>
> wrote:
>
>    
>>> The suggestion of an implementation note that describes the "common
>>> use" of the components and explains that some may be supported and
>>> others not is fine. In fact telling implementors that they need to be
>>> prepared for another system to reject a component would be good.
>>>        
>> I can get behind that.  I'd also like to recommend that systems not
>> reject a component silently -- a user needs to know if they imported a
>> iCalendar file and lost 50 VJOURNAL components in the process.
>>      
>
> Agreed.
>
> Note that iTIP does have a status code for "Unsupported Component" (3.13) -
> so informing the originator of the iCalendar data that they are sending
> something that is not supported by the recipient is covered by that.
>
> --
> Cyrus Daboo
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>    



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4740580CF9; Sat, 28 Jun 2008 07:18:36 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 762D314220D; Sat, 28 Jun 2008 07:18:36 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -4.532
X-Spam-Level: 
X-Spam-Status: No, score=-4.532 tagged_above=-50 required=4 tests=[AWL=2.068,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-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 g1o1GIL5T-x4; Sat, 28 Jun 2008 07:18:24 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6BBFB142203; Sat, 28 Jun 2008 07:18:24 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,719,1204520400"; d="scan'208";a="12555293"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 Jun 2008 10:18:14 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5SEIFQX012115;  Sat, 28 Jun 2008 10:18:15 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5SEIEGe024425; Sat, 28 Jun 2008 14:18:14 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Sat, 28 Jun 2008 10:18:14 -0400
Received: from elear-mac.local ([10.82.216.191]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Sat, 28 Jun 2008 10:18:13 -0400
Message-ID: <[e-mail]>
Date: Sat, 28 Jun 2008 16:18:13 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird/3.0a2pre (Macintosh; 2008062203)
MIME-Version: 1.0
To: Lisa Dusseault <[e-mail]>
References: <[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Jun 2008 14:18:14.0227 (UTC) FILETIME=[CD5B7A30:01C8D929]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=958; t=1214662695; x=1215526695; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20AD=20review=20issue=20#1=3A=20Use=20of= 20ALTREP |Sender:=20 |To:=20Lisa=20Dusseault=20<[e-mail]>; bh=+6p0IgFBROu2QqvTzXCl6AjnvgGQIJ4QT9OmrJhsmTU=; b=SBgydn9YK0Vkk4wzuT6eHWr5JLzmWzUwByRn8s7FnuhUywK69v1Is//6Fp ixxp8LmnFjGCg/KzkYKqwT+QKqbXko8O6zbTfplCmY1gibFtSO8M+MNuTXfR iBC2HWNBI1;
Authentication-Results: rtp-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
Subject: [Ietf-calsify] Re: AD review issue #1: Use of ALTREP
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 28 Jun 2008 14:18:36 -0000

Am I correct in that this issue is to be resolved as below?  Are there 
any objections?

Eliot

Lisa Dusseault wrote:
>
> On Jun 23, 2008, at 3:49 AM, Aki Niemi wrote:
>
>> May I suggest an alternative approach? Since the list of "known" uses of
>> ALTREP can actually be narrowed down to about three, I think we should
>> add to the definition of each of these properties exactly what it means
>> to receive one with the ALTREP parameter that contains an HTTP URL.
>> Other URIs permitted, but their meaning is undefined. In other words,
>> document current practice as much as we can, but keep further uses open.
>>
>> And then to ALTREP parameter, add the description you propose, as
>> generic advice to how the parameter should be handled/used.
>
> +1
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AEC4A80D1B for <[e-mail]>; Mon, 23 Jun 2008 09:22:30 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 389F5142211 for <[e-mail]>; Mon, 23 Jun 2008 09:22:31 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.778
X-Spam-Level: 
X-Spam-Status: No, score=-1.778 tagged_above=-50 required=4 tests=[AWL=0.128,  BAYES_00=-2.599, SPF_FAIL=0.693]
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 WEMYavp6xL0J; Mon, 23 Jun 2008 09:22:24 -0700 (PDT)
Received: from [10.1.1.149] (corp.collabrx.com [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D60811421F6; Mon, 23 Jun 2008 09:22:23 -0700 (PDT)
Message-Id: <[e-mail]>
From: Lisa Dusseault <[e-mail]>
To: Aki Niemi <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: AD review issue #1: Use of ALTREP (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Date: Mon, 23 Jun 2008 09:22:23 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Jun 2008 16:22:30 -0000

On Jun 23, 2008, at 3:49 AM, Aki Niemi wrote:

> May I suggest an alternative approach? Since the list of "known"  
> uses of
> ALTREP can actually be narrowed down to about three, I think we should
> add to the definition of each of these properties exactly what it  
> means
> to receive one with the ALTREP parameter that contains an HTTP URL.
> Other URIs permitted, but their meaning is undefined. In other words,
> document current practice as much as we can, but keep further uses  
> open.
>
> And then to ALTREP parameter, add the description you propose, as
> generic advice to how the parameter should be handled/used.

+1


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 54FE880D21; Mon, 23 Jun 2008 04:10:15 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D7384142203; Mon, 23 Jun 2008 04:10:15 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -5.64
X-Spam-Level: 
X-Spam-Status: No, score=-5.64 tagged_above=-50 required=4 tests=[AWL=0.959, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 30S5-L6PD1t0; Mon, 23 Jun 2008 04:10:06 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F5B81421F2; Mon, 23 Jun 2008 04:10:05 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5NB9TlM024858; Mon, 23 Jun 2008 14:09:38 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 23 Jun 2008 14:09:33 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 23 Jun 2008 14:09:26 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 14:09:23 +0300
Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5NB9MZR031157; Mon, 23 Jun 2008 14:09:22 +0300
Subject: Issue #6: Security Considerations (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[e-mail]>
To: ext Lisa Dusseault <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Organization: Nokia Devices R&D
Date: Mon, 23 Jun 2008 14:09:44 +0300
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jun 2008 11:09:23.0505 (UTC) FILETIME=[97A7C210:01C8D521]
X-Nokia-AV: Clean
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Jun 2008 11:10:15 -0000

ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > Section 7:  This is probably incomplete.  For example, there are  
> > attacks with embedded HTML that are well-known, and could apply to any  
> > usage of iCalendar.   Have we done brainstorming about other issues?

To my knowledge we have not. What might be helpful here are previous
examples of security considerations from similar work that could be used
as a basis. 

Cheers,
Aki




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1BE0C7F502; Mon, 23 Jun 2008 03:57:38 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9E1D3142206; Mon, 23 Jun 2008 03:57:38 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -5.584
X-Spam-Level: 
X-Spam-Status: No, score=-5.584 tagged_above=-50 required=4 tests=[AWL=1.015,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 PcBO1Ee8NHZf; Mon, 23 Jun 2008 03:57:32 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F3DA6142203; Mon, 23 Jun 2008 03:57:31 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5NAuVPV010331; Mon, 23 Jun 2008 13:56:32 +0300
Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 23 Jun 2008 13:55:26 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by vaebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 13:55:18 +0300
Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5NAtHL5031587; Mon, 23 Jun 2008 13:55:17 +0300
Subject: AD review issue #5: Meaning of Contact, Organizer and Recurrence ID in VJOURNAL (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[e-mail]>
To: ext Lisa Dusseault <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Organization: Nokia Devices R&D
Date: Mon, 23 Jun 2008 13:55:39 +0300
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jun 2008 10:55:18.0950 (UTC) FILETIME=[A042E460:01C8D51F]
X-Nokia-AV: Clean
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Jun 2008 10:57:38 -0000

Continuing with the second batch of the AD review comments...

ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > Section 3.8.4.3, 3.8.4.4:   CONTACT and ORGANIZER and RECURRENCE-ID  
> > are defined on VJOURNAL items.  I have no idea what they *mean* on  
> > VJOURNAL.

Can we safely remove VJOURNAL from the list of components for each of
these properties?

Cheers,
Aki




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B2D1A80D16; Mon, 23 Jun 2008 03:50:44 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 40268142203; Mon, 23 Jun 2008 03:50:45 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -5.521
X-Spam-Level: 
X-Spam-Status: No, score=-5.521 tagged_above=-50 required=4 tests=[AWL=1.078,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 w7+d4mA8xV1F; Mon, 23 Jun 2008 03:50:38 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BEE8F142211; Mon, 23 Jun 2008 03:50:38 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5NAn7Zr030242; Mon, 23 Jun 2008 05:50:26 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 23 Jun 2008 13:50:25 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 13:50:24 +0300
Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5NAoNW7026197; Mon, 23 Jun 2008 13:50:23 +0300
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in the same	iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[e-mail]>
To: ext Lisa Dusseault <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Organization: Nokia Devices R&D
Date: Mon, 23 Jun 2008 13:50:45 +0300
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jun 2008 10:50:24.0918 (UTC) FILETIME=[F1012B60:01C8D51E]
X-Nokia-AV: Clean
Cc: [e-mail], Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Jun 2008 10:50:44 -0000

ma, 2008-06-16 kello 09:25 -0700, ext Lisa Dusseault kirjoitti:
> I can get behind that.  I'd also like to recommend that systems not  
> reject a component silently -- a user needs to know if they imported a  
> iCalendar file and lost 50 VJOURNAL components in the process.

That's a good point.

Cheers,
Aki



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F3A3780D0D; Mon, 23 Jun 2008 03:50:27 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 820AE142211; Mon, 23 Jun 2008 03:50:28 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -5.449
X-Spam-Level: 
X-Spam-Status: No, score=-5.449 tagged_above=-50 required=4 tests=[AWL=1.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 3W3L-oB+yZFK; Mon, 23 Jun 2008 03:50:21 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 59BCB142206; Mon, 23 Jun 2008 03:50:21 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5NAnoNr002675; Mon, 23 Jun 2008 13:50:06 +0300
Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 23 Jun 2008 13:49:40 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jun 2008 13:49:39 +0300
Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5NAnZWs009236; Mon, 23 Jun 2008 13:49:37 +0300
Subject: Re: AD review issue #1: Use of ALTREP (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[e-mail]>
To: ext Lisa Dusseault <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain
Organization: Nokia Devices R&D
Date: Mon, 23 Jun 2008 13:49:57 +0300
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jun 2008 10:49:39.0287 (UTC) FILETIME=[D5CE6E70:01C8D51E]
X-Nokia-AV: Clean
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 23 Jun 2008 10:50:28 -0000

ma, 2008-06-16 kello 08:55 -0700, ext Lisa Dusseault kirjoitti:
> There are two issues here.  One is the attack vector, the other is  
> interoperability combinatorial problems.
> 
> The attack vector we can do very little about without really breaking  
> new ground in limiting where URLs can appear and what they can  
> contain.  Even then, if some Rails Web application has URLs of the  
> structure "http://calapp.example.org/lisa/e1234/delete" to mean  
> "Delete the event ID 'e1234' on the 'lisa' calendar" -- and if the  
> user has a cookie with a session giving them permissions to do this  
> action -- there's not much a client application can reasonably do to  
> detect that this might be a bad URL to go fetch.  (And a lot of the  
> worst examples are cases of poor Web app design.)

Right, I do agree there are a lot of things that bad web application
design is susceptible to here. But I don't see how this is especially
bad for iCalendar; it's simple enough to put URLs for images in an
HTML-formatted email, and achieve the same result. In fact, the
probablility of success in exploits this way is bound to be higher as
well (some mail applications actually follow the links).

> The interoperability issue from combinatorial explosions of where you  
> can find the ALTREP parameter and what can be in it, is not an attack  
> -- it can happen innocently and even when an application is trying to  
> do a creative extension to iCalendar.
> 
> One axis is the kind of URL you can see in ALTREP:  what would you do  
> with
> 
>        DESCRIPTION;ALTREP="imap://[e-mail]/INBOX":The  
> Fall'98 Wild
>          Wizards Conference - - Las Vegas\, NV\, USA
> 
> The other axis is seeing ALTREP in places where even if the URL scheme  
> is handled elsewhere in the client, it's unclear what it means in  
> context:
> 
>          DUE;ALTREP="http://timezones.example.org/tz/America-Los_Angeles.ics 
> ":19980430T000000Z
> 
> I don't have good answers about what to do about this.  If we lock  
> down what's allowed to a very narrow set of options, this limits  
> extensibility.  That would also be a lot of work.
> 
> Would it be too much work to collect a list, not necessarily complete,  
> of URL schemes that are used in ALTREP and a list of properties that  
> they're seen on ?  Then an implementation note could simply say  
> "Although the URL schemes used in ALTREP are not limited, in deployed  
> implementations as of 2008 one tends to see only HTTP URLs.   
> Similarly, although ALTREP can be used on any property, deployed  
> implementations seem to use it  (dereference and/or display) only when  
> it appears on the Comment, Description and Status properties, and the  
> parameter is often ignored on other properties."

Do you mean summary not status? 

May I suggest an alternative approach? Since the list of "known" uses of
ALTREP can actually be narrowed down to about three, I think we should
add to the definition of each of these properties exactly what it means
to receive one with the ALTREP parameter that contains an HTTP URL.
Other URIs permitted, but their meaning is undefined. In other words,
document current practice as much as we can, but keep further uses open.

And then to ALTREP parameter, add the description you propose, as
generic advice to how the parameter should be handled/used.

Cheers,
Aki


> Lisa
> 
> On Jun 16, 2008, at 2:56 AM, Aki Niemi wrote:
> 
> > ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> >>> Section 3.2.1:
> >>> The ALTREP parameter can be used in a lot of places.  I bet it's not
> >>> supported everywhere, and some usages of ALTREP could even be
> >>> dangerous.  Some health warnings should be added here at least.
> >
> > I think we have a couple of options here. Either limit exactly on what
> > properties the parameter can occur out of the TEXT value type
> > properties. Or, keep it as it is currently defined.
> >
> > In any case, some text should be added to the security considerations.
> > Specifically, what attack vector did you have in mind?
> >
> > Cheers,
> > Aki
> >
> 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E4D3780B19 for <[e-mail]>; Tue, 17 Jun 2008 09:47:51 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EB20E1421FF for <[e-mail]>; Tue, 17 Jun 2008 09:47:52 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.349
X-Spam-Level: 
X-Spam-Status: No, score=-1.349 tagged_above=-50 required=4 tests=[AWL=1.251,  BAYES_00=-2.599, SPF_PASS=-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 UU1mwJKryrDu for <[e-mail]>; Tue, 17 Jun 2008 09:47:41 -0700 (PDT)
Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by laweleka.osafoundation.org (Postfix) with ESMTP id C7897142202 for <[e-mail]>; Tue, 17 Jun 2008 09:47:40 -0700 (PDT)
Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA01.westchester.pa.mail.comcast.net with comcast id f42n1Z0030QuhwU5103i00; Tue, 17 Jun 2008 16:47:38 +0000
Received: from THare ([71.203.105.66]) by OMTA02.westchester.pa.mail.comcast.net with comcast id f4na1Z00G1RyUCv3N4nexz; Tue, 17 Jun 2008 16:47:38 +0000
X-Authority-Analysis: v=1.0 c=1 a=09V5aE_Pek8A:10 a=n7_MfodNLFUA:10 a=PFsjAnyDAAAA:8 a=Zb1jeGHfSl49vJZKdtIA:9 a=Y4DPbSm8Budz6nVa01kA:7 a=Njz9VVKFp4iHHUTGBzu2m-x5W74A:4 a=YewFc9KQ5U8A:10 a=9XSpoOj3B7kA:10
From: "Tim Hare" <[e-mail]>
To: "'Cyrus Daboo'" <[e-mail]>, "'Lisa Dusseault'" <[e-mail]>
Subject: RE: AD review issue #4: Supporting both VTODO and VEVENT in thesame	iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)
Date: Tue, 17 Jun 2008 12:47:40 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <[e-mail]>
Thread-Index: AcjPzq1u6YpXsLHwQTGO0rQF3EZfmgAyoc7A
Message-Id: <[e-mail]>
Cc: [e-mail], 'Bernard Desruisseaux' <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 17 Jun 2008 16:47:52 -0000

As an "informed user" - i.e. not a developer, I definitely support
NON-silent rejection.  I can agree with non-support of certain components
only if I receive some notification;  due to work requirements I am now
journalling my time on some projects, and it would be good to know if I
can't import that data into another tool.


Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Cyrus Daboo
Sent: Monday, June 16, 2008 12:33 PM
To: Lisa Dusseault
Cc: [e-mail]; Bernard Desruisseaux
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in thesame
iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on2445bis)

Hi Lisa,

--On June 16, 2008 9:25:14 AM -0700 Lisa Dusseault <[e-mail]>
wrote:

>> The suggestion of an implementation note that describes the "common 
>> use" of the components and explains that some may be supported and 
>> others not is fine. In fact telling implementors that they need to be 
>> prepared for another system to reject a component would be good.
>
> I can get behind that.  I'd also like to recommend that systems not 
> reject a component silently -- a user needs to know if they imported a 
> iCalendar file and lost 50 VJOURNAL components in the process.

Agreed.

Note that iTIP does have a status code for "Unsupported Component" (3.13) -
so informing the originator of the iCalendar data that they are sending
something that is not supported by the recipient is covered by that.

--
Cyrus Daboo

_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E8F1780B68; Mon, 16 Jun 2008 09:33:00 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 001231421F6; Mon, 16 Jun 2008 09:33:01 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.511
X-Spam-Level: 
X-Spam-Status: No, score=-2.511 tagged_above=-50 required=4 tests=[AWL=0.088,  BAYES_00=-2.599]
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 UtrRct1dVEHz; Mon, 16 Jun 2008 09:32:54 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 626D51421FF; Mon, 16 Jun 2008 09:32:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id B29958D88BF; Mon, 16 Jun 2008 12:32:52 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp9pYdPO1yft; Mon, 16 Jun 2008 12:32:52 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 1AB168D88B5; Mon, 16 Jun 2008 12:32:50 -0400 (EDT)
Date: Mon, 16 Jun 2008 12:32:48 -0400
From: Cyrus Daboo <[e-mail]>
To: Lisa Dusseault <[e-mail]>
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in the same	iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: [e-mail], Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 16:33:01 -0000

Hi Lisa,

--On June 16, 2008 9:25:14 AM -0700 Lisa Dusseault <[e-mail]> 
wrote:

>> The suggestion of an implementation note that describes the "common
>> use" of the components and explains that some may be supported and
>> others not is fine. In fact telling implementors that they need to
>> be prepared for another system to reject a component would be good.
>
> I can get behind that.  I'd also like to recommend that systems not
> reject a component silently -- a user needs to know if they imported a
> iCalendar file and lost 50 VJOURNAL components in the process.

Agreed.

Note that iTIP does have a status code for "Unsupported Component" (3.13) - 
so informing the originator of the iCalendar data that they are sending 
something that is not supported by the recipient is covered by that.

-- 
Cyrus Daboo



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 509A780BAB for <[e-mail]>; Mon, 16 Jun 2008 09:25:24 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BD201421FF for <[e-mail]>; Mon, 16 Jun 2008 09:25:25 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.757
X-Spam-Level: 
X-Spam-Status: No, score=-1.757 tagged_above=-50 required=4 tests=[AWL=0.149,  BAYES_00=-2.599, SPF_FAIL=0.693]
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 HJysbu+kGIhu; Mon, 16 Jun 2008 09:25:15 -0700 (PDT)
Received: from [10.1.1.149] (corp.collabrx.com [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CA1AF1421F6; Mon, 16 Jun 2008 09:25:15 -0700 (PDT)
Message-Id: <[e-mail]>
From: Lisa Dusseault <[e-mail]>
To: Cyrus Daboo <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in the same	iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Date: Mon, 16 Jun 2008 09:25:14 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
Cc: [e-mail], Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 16:25:24 -0000

On Jun 16, 2008, at 9:11 AM, Cyrus Daboo wrote:

> Hi Lisa,
>
> --On June 16, 2008 9:01:07 AM -0700 Lisa Dusseault <[e-mail] 
> > wrote:
>
>>> Isn't this the implicit assumption already? Namely that if an
>>> implementation is conforming to the specification, it must supports
>>> all
>>> of the defined components therein?
>>
>> I should add that currently VTODO and VJOURNAL are treated exactly  
>> the
>> same way as far as requirements are concerned, even though real- 
>> world use
>> of VTODO is much greater than for VJOURNAL and I'm not even sure we  
>> can
>> explain how people use VJOURNAL.  So it seems odd that they're both
>> assumed to be required but one is really used and the other is  
>> not.  That
>> kind of thing may lead casual implementors to just ignore the  
>> implicit
>> requirement, and lump VTODO in with VJOURNAL as something they don't
>> really want to figure out how to support.
>>
>> Again, I can't think of any new requirement that would be a  
>> definite good
>> thing, but we could easily write an implementation note that mentions
>> that VTODOs are increasingly seen in exported ICS files and even in  
>> iTIP
>> messages and that VEVENTS are ubiquitous.
>
> I don't think we can require support of all components. I think it  
> is perfectly fine for a "task management" application to only  
> support VTODOs and still claim to be iCalendar compliant.
>
> The suggestion of an implementation note that describes the "common  
> use" of the components and explains that some may be supported and  
> others not is fine. In fact telling implementors that they need to  
> be prepared for another system to reject a component would be good.

I can get behind that.  I'd also like to recommend that systems not  
reject a component silently -- a user needs to know if they imported a  
iCalendar file and lost 50 VJOURNAL components in the process.

Lisa



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CAB6C80B48; Mon, 16 Jun 2008 09:12:13 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D5A5F1421F1; Mon, 16 Jun 2008 09:12:14 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.51
X-Spam-Level: 
X-Spam-Status: No, score=-2.51 tagged_above=-50 required=4 tests=[AWL=0.089, BAYES_00=-2.599]
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 9uWjkPdOF-ZZ; Mon, 16 Jun 2008 09:12:05 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id 23E111421F6; Mon, 16 Jun 2008 09:12:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 887A88D859F; Mon, 16 Jun 2008 12:12:03 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8MxQLq1qV-G; Mon, 16 Jun 2008 12:12:03 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id B01428D8598; Mon, 16 Jun 2008 12:12:01 -0400 (EDT)
Date: Mon, 16 Jun 2008 12:11:59 -0400
From: Cyrus Daboo <[e-mail]>
To: Lisa Dusseault <[e-mail]>, Aki Niemi <[e-mail]>
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in the same	iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: [e-mail], Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 16:12:13 -0000

Hi Lisa,

--On June 16, 2008 9:01:07 AM -0700 Lisa Dusseault <[e-mail]> 
wrote:

>> Isn't this the implicit assumption already? Namely that if an
>> implementation is conforming to the specification, it must supports
>> all
>> of the defined components therein?
>
> I should add that currently VTODO and VJOURNAL are treated exactly the
> same way as far as requirements are concerned, even though real-world use
> of VTODO is much greater than for VJOURNAL and I'm not even sure we can
> explain how people use VJOURNAL.  So it seems odd that they're both
> assumed to be required but one is really used and the other is not.  That
> kind of thing may lead casual implementors to just ignore the implicit
> requirement, and lump VTODO in with VJOURNAL as something they don't
> really want to figure out how to support.
>
> Again, I can't think of any new requirement that would be a definite good
> thing, but we could easily write an implementation note that mentions
> that VTODOs are increasingly seen in exported ICS files and even in iTIP
> messages and that VEVENTS are ubiquitous.

I don't think we can require support of all components. I think it is 
perfectly fine for a "task management" application to only support VTODOs 
and still claim to be iCalendar compliant.

The suggestion of an implementation note that describes the "common use" of 
the components and explains that some may be supported and others not is 
fine. In fact telling implementors that they need to be prepared for 
another system to reject a component would be good.

-- 
Cyrus Daboo



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8BEF480BAB; Mon, 16 Jun 2008 09:08:01 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 976CD1421F6; Mon, 16 Jun 2008 09:08:02 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.51
X-Spam-Level: 
X-Spam-Status: No, score=-2.51 tagged_above=-50 required=4 tests=[AWL=0.089, BAYES_00=-2.599]
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 DPNkkvQFw+nU; Mon, 16 Jun 2008 09:07:51 -0700 (PDT)
Received: from daboo.name (daboo.name [151.201.22.177]) by laweleka.osafoundation.org (Postfix) with ESMTP id D39B51421F1; Mon, 16 Jun 2008 09:07:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id EA0648D8413; Mon, 16 Jun 2008 12:07:48 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiwQc0K-937l; Mon, 16 Jun 2008 12:07:48 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 0DC6E8D840B; Mon, 16 Jun 2008 12:07:46 -0400 (EDT)
Date: Mon, 16 Jun 2008 12:07:44 -0400
From: Cyrus Daboo <[e-mail]>
To: Aki Niemi <[e-mail]>, ext Lisa Dusseault <[e-mail]>
Subject: Re: AD review issue #2: DIR parameter (was: Re: [Ietf-calsify] Re: AD	review on 2445bis)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: [e-mail], Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 16:08:01 -0000

Hi Aki,

--On June 16, 2008 12:59:12 PM +0300 Aki Niemi <[e-mail]> wrote:

>> > Section 3.2.6, DIR parameter:  This should be limited to LDAP URLs
>> > only, if not by requirement then at least by noting that other types
>> > of URLs are likely to be harmful to interoperability.
>
> For maximum interoperability, a mandatory-to-implement choice should be
> defined. However, is LDAP even widely enough supported in iCalendar
> implementations to justify this? I suspect vCardDAV URLs could in the
> future start appearing here as well.

I think at the very least HTTP/HTTPS needs to be allowed as well.

-- 
Cyrus Daboo



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6022C80B68 for <[e-mail]>; Mon, 16 Jun 2008 09:01:18 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6A477142204 for <[e-mail]>; Mon, 16 Jun 2008 09:01:19 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.757
X-Spam-Level: 
X-Spam-Status: No, score=-1.757 tagged_above=-50 required=4 tests=[AWL=0.149,  BAYES_00=-2.599, SPF_FAIL=0.693]
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 7NJN46y61HsY; Mon, 16 Jun 2008 09:01:08 -0700 (PDT)
Received: from [10.1.1.149] (corp.collabrx.com [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8289D1421F6; Mon, 16 Jun 2008 09:01:08 -0700 (PDT)
Message-Id: <[e-mail]>
From: Lisa Dusseault <[e-mail]>
To: Aki Niemi <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: AD review issue #4: Supporting both VTODO and VEVENT in the same iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Date: Mon, 16 Jun 2008 09:01:07 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 16:01:18 -0000

On Jun 16, 2008, at 3:14 AM, Aki Niemi wrote:

> ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
>>> Section 3.6.2: VTODO.  Is it now more common for VTODOs to appear in
>>> the same iCalendar document as VEVENTS?  A few years ago that was  
>>> not
>>> the case.  Can we now state that user agents SHOULD be able to  
>>> handle
>>> VTODOs as well as VEVENTS?
>
> Isn't this the implicit assumption already? Namely that if an
> implementation is conforming to the specification, it must supports  
> all
> of the defined components therein?

I should add that currently VTODO and VJOURNAL are treated exactly the  
same way as far as requirements are concerned, even though real-world  
use of VTODO is much greater than for VJOURNAL and I'm not even sure  
we can explain how people use VJOURNAL.  So it seems odd that they're  
both assumed to be required but one is really used and the other is  
not.  That kind of thing may lead casual implementors to just ignore  
the implicit requirement, and lump VTODO in with VJOURNAL as something  
they don't really want to figure out how to support.

Again, I can't think of any new requirement that would be a definite  
good thing, but we could easily write an implementation note that  
mentions that VTODOs are increasingly seen in exported ICS files and  
even in iTIP messages and that VEVENTS are ubiquitous.

Lisa


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8702F80B5E for <[e-mail]>; Mon, 16 Jun 2008 08:55:59 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8DF781421FF for <[e-mail]>; Mon, 16 Jun 2008 08:56:00 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -1.757
X-Spam-Level: 
X-Spam-Status: No, score=-1.757 tagged_above=-50 required=4 tests=[AWL=0.149,  BAYES_00=-2.599, SPF_FAIL=0.693]
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 iL74-fTTLTbn; Mon, 16 Jun 2008 08:55:54 -0700 (PDT)
Received: from [10.1.1.149] (corp.collabrx.com [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0CAF41421F6; Mon, 16 Jun 2008 08:55:54 -0700 (PDT)
Message-Id: <[e-mail]>
From: Lisa Dusseault <[e-mail]>
To: Aki Niemi <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: AD review issue #1: Use of ALTREP (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
Date: Mon, 16 Jun 2008 08:55:52 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Apple Mail (2.924)
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 15:55:59 -0000

There are two issues here.  One is the attack vector, the other is  
interoperability combinatorial problems.

The attack vector we can do very little about without really breaking  
new ground in limiting where URLs can appear and what they can  
contain.  Even then, if some Rails Web application has URLs of the  
structure "http://calapp.example.org/lisa/e1234/delete" to mean  
"Delete the event ID 'e1234' on the 'lisa' calendar" -- and if the  
user has a cookie with a session giving them permissions to do this  
action -- there's not much a client application can reasonably do to  
detect that this might be a bad URL to go fetch.  (And a lot of the  
worst examples are cases of poor Web app design.)

The interoperability issue from combinatorial explosions of where you  
can find the ALTREP parameter and what can be in it, is not an attack  
-- it can happen innocently and even when an application is trying to  
do a creative extension to iCalendar.

One axis is the kind of URL you can see in ALTREP:  what would you do  
with

       DESCRIPTION;ALTREP="imap://[e-mail]/INBOX":The  
Fall'98 Wild
         Wizards Conference - - Las Vegas\, NV\, USA

The other axis is seeing ALTREP in places where even if the URL scheme  
is handled elsewhere in the client, it's unclear what it means in  
context:

         DUE;ALTREP="http://timezones.example.org/tz/America-Los_Angeles.ics 
":19980430T000000Z

I don't have good answers about what to do about this.  If we lock  
down what's allowed to a very narrow set of options, this limits  
extensibility.  That would also be a lot of work.

Would it be too much work to collect a list, not necessarily complete,  
of URL schemes that are used in ALTREP and a list of properties that  
they're seen on ?  Then an implementation note could simply say  
"Although the URL schemes used in ALTREP are not limited, in deployed  
implementations as of 2008 one tends to see only HTTP URLs.   
Similarly, although ALTREP can be used on any property, deployed  
implementations seem to use it  (dereference and/or display) only when  
it appears on the Comment, Description and Status properties, and the  
parameter is often ignored on other properties."

Lisa

On Jun 16, 2008, at 2:56 AM, Aki Niemi wrote:

> ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
>>> Section 3.2.1:
>>> The ALTREP parameter can be used in a lot of places.  I bet it's not
>>> supported everywhere, and some usages of ALTREP could even be
>>> dangerous.  Some health warnings should be added here at least.
>
> I think we have a couple of options here. Either limit exactly on what
> properties the parameter can occur out of the TEXT value type
> properties. Or, keep it as it is currently defined.
>
> In any case, some text should be added to the security considerations.
> Specifically, what attack vector did you have in mind?
>
> Cheers,
> Aki
>



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D24577F528; Mon, 16 Jun 2008 03:37:37 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E0C001421F2; Mon, 16 Jun 2008 03:37:38 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -5.367
X-Spam-Level: 
X-Spam-Status: No, score=-5.367 tagged_above=-50 required=4 tests=[AWL=1.232,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 EHlqpkBheXto; Mon, 16 Jun 2008 03:37:24 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C043B1421FF; Mon, 16 Jun 2008 03:37:23 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5GAaH33001456; Mon, 16 Jun 2008 13:36:29 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 16 Jun 2008 13:06:15 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 13:06:15 +0300
Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5GA6EiE017622; Mon, 16 Jun 2008 13:06:14 +0300
Subject: AD review issue #3: Meaning of RELTYPE parameter value of SIBLING (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[e-mail]>
To: ext Lisa Dusseault <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Organization: Nokia Devices R&D
Date: Mon, 16 Jun 2008 13:06:15 +0300
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jun 2008 10:06:15.0504 (UTC) FILETIME=[9CF06D00:01C8CF98]
X-Nokia-AV: Clean
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 10:37:38 -0000

ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > Section 3.2.15: RELTYPE.  What does it mean that a calendar component  
> > referenced is the SIBLING of this one?  How is a user agent supposed  
> > to use this information?  Is this parameter ever used except on  
> > RELATED-TO?  Is it actually in use even there?  Health warnings at  
> > least.

Good question. Is there a use case that requires a relationship beyond
parent-child (which currently is the only *defined* relationship in the
document anyway)?

Cheers,
Aki



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4978A80898; Mon, 16 Jun 2008 03:36:56 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 575B01421F2; Mon, 16 Jun 2008 03:36:57 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -5.272
X-Spam-Level: 
X-Spam-Status: No, score=-5.272 tagged_above=-50 required=4 tests=[AWL=1.327,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 mSOYDjRRjVMF; Mon, 16 Jun 2008 03:36:50 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CF55F1421FF; Mon, 16 Jun 2008 03:36:50 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5GAZXSP002265; Mon, 16 Jun 2008 05:36:37 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 16 Jun 2008 13:14:45 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 13:14:44 +0300
Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5GAEh99029823; Mon, 16 Jun 2008 13:14:43 +0300
Subject: AD review issue #4: Supporting both VTODO and VEVENT in the same iCalendar stream (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[e-mail]>
To: ext Lisa Dusseault <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Organization: Nokia Devices R&D
Date: Mon, 16 Jun 2008 13:14:44 +0300
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jun 2008 10:14:44.0607 (UTC) FILETIME=[CC6360F0:01C8CF99]
X-Nokia-AV: Clean
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 10:36:56 -0000

ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > Section 3.6.2: VTODO.  Is it now more common for VTODOs to appear in  
> > the same iCalendar document as VEVENTS?  A few years ago that was not  
> > the case.  Can we now state that user agents SHOULD be able to handle  
> > VTODOs as well as VEVENTS?

Isn't this the implicit assumption already? Namely that if an
implementation is conforming to the specification, it must supports all
of the defined components therein?

Cheers,
Aki



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 82CFC7F54A; Mon, 16 Jun 2008 03:36:50 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 90D97142204; Mon, 16 Jun 2008 03:36:51 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -5.161
X-Spam-Level: 
X-Spam-Status: No, score=-5.161 tagged_above=-50 required=4 tests=[AWL=1.438,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 iRRWxghlKQnv; Mon, 16 Jun 2008 03:36:44 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8CA441421F2; Mon, 16 Jun 2008 03:36:44 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5GAaE6F001402; Mon, 16 Jun 2008 13:36:29 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 16 Jun 2008 12:59:12 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 12:59:12 +0300
Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5G9xAgx014167; Mon, 16 Jun 2008 12:59:11 +0300
Subject: AD review issue #2: DIR parameter (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[e-mail]>
To: ext Lisa Dusseault <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Organization: Nokia Devices R&D
Date: Mon, 16 Jun 2008 12:59:12 +0300
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jun 2008 09:59:12.0432 (UTC) FILETIME=[A0C4C300:01C8CF97]
X-Nokia-AV: Clean
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 10:36:50 -0000

ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > Section 3.2.6, DIR parameter:  This should be limited to LDAP URLs  
> > only, if not by requirement then at least by noting that other types  
> > of URLs are likely to be harmful to interoperability.

For maximum interoperability, a mandatory-to-implement choice should be
defined. However, is LDAP even widely enough supported in iCalendar
implementations to justify this? I suspect vCardDAV URLs could in the
future start appearing here as well.

Cheers,
Aki



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A139F7F541; Mon, 16 Jun 2008 02:56:54 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AE9771421FF; Mon, 16 Jun 2008 02:56:55 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -5.03
X-Spam-Level: 
X-Spam-Status: No, score=-5.03 tagged_above=-50 required=4 tests=[AWL=1.569, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 u4fJPxZTeRw8; Mon, 16 Jun 2008 02:56:44 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5F0351421F2; Mon, 16 Jun 2008 02:56:44 -0700 (PDT)
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5G9u9r0000975; Mon, 16 Jun 2008 12:56:29 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 16 Jun 2008 12:56:16 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 12:56:15 +0300
Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5G9uDwx007208; Mon, 16 Jun 2008 12:56:14 +0300
Subject: AD review issue #1: Use of ALTREP (was: Re: [Ietf-calsify] Re: AD review on 2445bis)
From: Aki Niemi <[e-mail]>
To: ext Lisa Dusseault <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain
Organization: Nokia Devices R&D
Date: Mon, 16 Jun 2008 12:56:14 +0300
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jun 2008 09:56:15.0778 (UTC) FILETIME=[37798020:01C8CF97]
X-Nokia-AV: Clean
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 09:56:54 -0000

ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
> > Section 3.2.1:
> > The ALTREP parameter can be used in a lot of places.  I bet it's not  
> > supported everywhere, and some usages of ALTREP could even be  
> > dangerous.  Some health warnings should be added here at least.

I think we have a couple of options here. Either limit exactly on what
properties the parameter can occur out of the TEXT value type
properties. Or, keep it as it is currently defined. 

In any case, some text should be added to the security considerations.
Specifically, what attack vector did you have in mind?

Cheers,
Aki



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1C3DA80898; Mon, 16 Jun 2008 00:04:39 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2ACB31421FF; Mon, 16 Jun 2008 00:04:40 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -4.874
X-Spam-Level: 
X-Spam-Status: No, score=-4.874 tagged_above=-50 required=4 tests=[AWL=1.725,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 V5t1BzJO6Jin; Mon, 16 Jun 2008 00:04:33 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id AB4F81421F2; Mon, 16 Jun 2008 00:04:32 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5G705CF010382; Mon, 16 Jun 2008 10:03:28 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 16 Jun 2008 10:03:27 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 16 Jun 2008 10:03:26 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 10:03:23 +0300
Received: from [172.21.43.43] (esdhcp04343.research.nokia.com [172.21.43.43]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m5G73IkD027574; Mon, 16 Jun 2008 10:03:22 +0300
From: Aki Niemi <[e-mail]>
To: ext Lisa Dusseault <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Organization: Nokia Devices R&D
Date: Mon, 16 Jun 2008 10:03:18 +0300
Message-Id: <[e-mail]>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Jun 2008 07:03:24.0008 (UTC) FILETIME=[116AFE80:01C8CF7F]
X-Nokia-AV: Clean
Cc: "[e-mail]" <[e-mail]>, Bernard Desruisseaux <[e-mail]>
Subject: [Ietf-calsify] Re: AD review on 2445bis
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2008 07:04:39 -0000

[CC'd the working group list]

Hi Lisa,

Overall, I think these comments fall into two categories; editorial and
substantial. I've labeled the issues below, and will start a new thread
on each substantial issue on the list.

AFAIK, none of the issues you mention have been brought up before. In
other words, good catches. ;)

Cheers,
Aki

to, 2008-05-29 kello 13:49 -0700, ext Lisa Dusseault kirjoitti:
> Section references:  Can we break section 3 down for publication?  It  
> would be so much easier to remember and refer to specific sections of  
> this document if we had section "4.4." be the UID parameter section  
> instead of 3.8.4.7.    My eyes just cross at the fourth level of  
> section nesting.  I am probably abnormally insistent about avoiding  
> that fourth hierarchy level, and you may all think I'm crazy to  
> suggest the work and change.  Nevertheless, I'll go ahead and suggest,  
> without any further pressure, a breakdown and ordering that I,  
> speaking as an individual and not as an AD (is that enough  
> disclaimers), would prefer:
> 	Section 3:   iCalendar Syntax
> 		Section 3.1: Content lines
> 		Section 3.2: Value Data Types
> 
> 	Section 4: ICalendar ojects and Components
>   		Section 4.1: iCalendar object
> 		Section 4.2: Components
> 
> 	Section 5: Properties
> 		Section 5.1: Property Parameters
> 		Section 5.2: Calendar Properties
> 		Section 5.3: Descriptive Component Properties
> 		Section 5.4: Date and Time Component Properties
> 		Section 5.5: Time Zone Component Properties
> 		Section 5.6: Relationship Component Properties
> 		Section 5.7: Recurrence Component Properties
> 		Section 5.8: Alarm Component Properties
> 		Section 5.9: Change Management Component Properties
> 		Section 5.10: Miscellaneous Component Properties
> 
> 	Section 6: iCalendar Object examples
> 
> 	... all further sections ++2

[editorial]

I think this change makes sense.

> Section -by-section comments:
> 
> Section 1: This sentence is really out of date/touch:
> 					However, the longer term growth of
>     calendaring and scheduling is currently limited by the lack of
>     Internet standards for the message content types that are central to
>     these knowledgeware applications.
> 
> I think we can just drop it unless you think there's something  
> important to preserve.

[editorial]

I agree.

> Section 3.2.1:
> The ALTREP parameter can be used in a lot of places.  I bet it's not  
> supported everywhere, and some usages of ALTREP could even be  
> dangerous.  Some health warnings should be added here at least.

[substantial]

I think this is also related to another issue listed below on
strengthening the security considerations section of the draft.

> Section 3.2.6, DIR parameter:  This should be limited to LDAP URLs  
> only, if not by requirement then at least by noting that other types  
> of URLs are likely to be harmful to interoperability.

[substantial]

> Section 3.2.10: When a language tag can be used to distinguish between  
> multiple values, we do need a little guidance about how this is  
> intended to be used.  How is it used in practice?   Are clients  
> expected to display only the one that is their most preferred language  
> among the choices, or are clients expected to display all values and  
> use the language tag to help display properly?

[editorial]

I suspect this simply needs an implementation note on the subject.

> Section 3.2.15: RELTYPE.  What does it mean that a calendar component  
> referenced is the SIBLING of this one?  How is a user agent supposed  
> to use this information?  Is this parameter ever used except on  
> RELATED-TO?  Is it actually in use even there?  Health warnings at  
> least.

[substantial]

> Section 3.6.2: VTODO.  Is it now more common for VTODOs to appear in  
> the same iCalendar document as VEVENTS?  A few years ago that was not  
> the case.  Can we now state that user agents SHOULD be able to handle  
> VTODOs as well as VEVENTS?

[substantial]

> Section 3.6.3: VJOURNAL: This needs a health warning even more than  
> VTODO does; some discussion about what users actually do with VJOURNAL  
> components, if ever, but nevertheless how preserving user data is  
> important...

[substantial]

> Section 3.8.1.10:  Is there some colloquial meaning of "raton- 
> laveur"?  A naive translation has this as "small rat washer"  and I'm  
> intrigued by why this would be a required resource for an event...  :)

[editorial]

Bernard? 

> Section 3.8.4.3, 3.8.4.4:   CONTACT and ORGANIZER and RECURRENCE-ID  
> are defined on VJOURNAL items.  I have no idea what they *mean* on  
> VJOURNAL.

[substantial]

> Section 3.8.8.2:  X- Properties:  We should recommend AGAINST using  
> these with user-readable strings like

I think there's some text missing here. Can you clarify?

> Section 5:  List item 2 is blank. So is #7.

[editorial]

> Section 7:  This is probably incomplete.  For example, there are  
> attacks with embedded HTML that are well-known, and could apply to any  
> usage of iCalendar.   Have we done brainstorming about other issues?

[substantial]

> Section 8:  It would help to add that we are now *updating* IANA  
> registries that were first established with RFC 2445.  (If we're not  
> making any changes, it would be good to say that instead).  IANA reads  
> this section mostly, and depends on this section to figure out what to  
> do...  Since these registries already exist, we can now put URLs in to  
> this document to be extra helpful to readers and to the IANA.

[editorial]

Good point.

Cheers,
Aki



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9007B80BF3 for <[e-mail]>; Mon,  9 Jun 2008 19:02:51 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1567D1421F6 for <[e-mail]>; Mon,  9 Jun 2008 19:02:53 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -0.51
X-Spam-Level: 
X-Spam-Status: No, score=-0.51 tagged_above=-50 required=4 tests=[AWL=0.649, BAYES_00=-2.599, FB_CIALIS_LEO3=1.441, SPF_PASS=-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 7lCOYS8Ult1Z for <[e-mail]>; Mon,  9 Jun 2008 19:02:42 -0700 (PDT)
Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by laweleka.osafoundation.org (Postfix) with ESMTP id 23DE81421F2 for <[e-mail]>; Mon,  9 Jun 2008 19:02:41 -0700 (PDT)
Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA04.westchester.pa.mail.comcast.net with comcast id bqGX1Z0030Fqzac540m300; Tue, 10 Jun 2008 02:02:39 +0000
Received: from THare ([71.203.105.66]) by OMTA08.westchester.pa.mail.comcast.net with comcast id c22X1Z00M1RyUCv3U22dRt; Tue, 10 Jun 2008 02:02:37 +0000
X-Authority-Analysis: v=1.0 c=1 a=8oAFx5Ev2jcA:10 a=CwJLALZJc7AA:10 a=48vgC7mUAAAA:8 a=VE6_KAKKAAAA:8 a=alhiumpZ6VvY5ixAtagA:9 a=GDIHq1vkDNhWtaLQCLIA:7 a=OgeyCgafCeH2-slV_6T1B4JSlPAA:4 a=YewFc9KQ5U8A:10 a=lZB815dzVvQA:10 a=JBuORb3gVlEA:10
From: "Tim Hare" <[e-mail]>
To: <[e-mail]>
Subject: RE: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt 
Date: Mon, 9 Jun 2008 22:02:35 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcjKWrrOcZ69sd4hRq6/TZ5pS6QXxwAQVtKg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 10 Jun 2008 02:02:51 -0000

3.1 

"   1. The iCalendar object MUST be signed by the "Organizer" sending an
   update/initial request or the "Attendee" sending a reply.  <<Or the
   person sending on their behalf? Clearly if somebody else is sending
   the invitation, she can't sign using the key belonging to the
   organizer>>"

This might impact ITIP and possibly iCal, but we may need a mechanism for an
Organizer to sign a security token when creating/authorizing a delegate, and
require that token to be present in anything sent on the Organizer's behalf.
This would be signed by the Organizer with the Organizer's private key, so
that it would be verifiable by decrypting it with the Organizer's public
key. I'm not a security expert, but it could be as simple as encrypting the
Organizer's RFC2822 address as the token and then upon decryption verifying
that it matched that of the Organizer.

After 3.5
 
"If an unsigned iMIP message is received from the same
   sender later on, the receiving CUA SHOULD warn the user about a
   possible man-in-the-middle attack and SHOULD ignore the message,
   unless explicitly overriden by the user. <<Should it also try to
   notify the other end?>>"

I would suggest that the answer to this question is "No", because if the
attacker has successfully interposed itself between the "other end" and this
CUA, any notification attempt would notify the attacker, allowing it to
withdraw and remove traces.





Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Monday, June 09, 2008 2:00 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-05.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-05.txt
	Pages		: 22
	Date		: 2008-6-9
	
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-05.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
implementation to automatically retrieve the ASCII version of the
Internet-Draft.




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 129AC80ABF for <[e-mail]>; Mon,  9 Jun 2008 11:00:36 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9A95C1421FF for <[e-mail]>; Mon,  9 Jun 2008 11:00:37 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -3.809
X-Spam-Level: 
X-Spam-Status: No, score=-3.809 tagged_above=-50 required=4 tests=[AWL=2.790,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 LsbcUGD807OX for <[e-mail]>; Mon,  9 Jun 2008 11:00:24 -0700 (PDT)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0EF9F1421FD for <[e-mail]>; Mon,  9 Jun 2008 11:00:23 -0700 (PDT)
Received: by core3.amsl.com (Postfix, from userid 0) id 4DED13A6ACB; Mon,  9 Jun 2008 11:00:01 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  9 Jun 2008 11:00:02 -0700 (PDT)
Cc: [e-mail]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2447bis-05.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 09 Jun 2008 18:00:36 -0000

--NextPart

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-05.txt
	Pages		: 22
	Date		: 2008-6-9
	
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-05.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
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2447bis-05.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[e-mail]>


--NextPart--



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2A2D67F54A for <[e-mail]>; Tue,  3 Jun 2008 05:15:36 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 088361421FB for <[e-mail]>; Tue,  3 Jun 2008 05:15:38 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -4.183
X-Spam-Level: 
X-Spam-Status: No, score=-4.183 tagged_above=-50 required=4 tests=[AWL=2.417,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SPF_PASS=-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 zBE7KTDd6vZy for <[e-mail]>; Tue,  3 Jun 2008 05:15:23 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A1C0E1421F2 for <[e-mail]>; Tue,  3 Jun 2008 05:15:22 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,582,1204498800"; d="scan'208";a="10618728"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2008 14:15:18 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m53CFI5e012202;  Tue, 3 Jun 2008 14:15:18 +0200
Received: from adsl-247-3-fixip.tiscali.ch (dhcp-10-61-98-22.cisco.com [10.61.98.22]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m53CFImN019363; Tue, 3 Jun 2008 12:15:18 GMT
Message-ID: <[e-mail]>
Date: Tue, 03 Jun 2008 14:15:18 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 3.0a2pre (Macintosh/2008060103)
MIME-Version: 1.0
To: Eliot Lear <[e-mail]>
Subject: Re: [Ietf-calsify] WGLC: draft-ietf-calsify-2446bis-06.txt && IETF Dublin
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=193; t=1212495318; x=1213359318; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20WGLC=3A=20draft-ietf-c alsify-2446bis-06.txt=20&&=20IETF=0A=20Dublin |Sender:=20; bh=bODeOtS17FkFJ3WOIaRmiGuQvnzaUtNKY48cnU2lea0=; b=KklwoUoghjUHBgiMSfQLwuaL54bFonTdyv0r+PK0C+oxfeXXZmQBjWGr6l anXBrjxilgrG1bGXsjdR8PWFCbIfX7h+iYMjqEN6KR4C3MWb2WJQ0On4PlKJ KEvDzdlXHB;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 
Cc: "[e-mail]" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 03 Jun 2008 12:15:36 -0000

Dear all,

This is a reminder that draft-ietf-calsify-2446bis-06.txt is in working 
group last call (WGLC).  Please submit any comments you have now.  Last 
call ends on June 15.

Eliot