Re: [secdir] SECDIR review of draft-ietf-lemonade-profile-bis-12.txt

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 11 March 2009 16:05 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A2428C158 for <secdir@core3.amsl.com>; Wed, 11 Mar 2009 09:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level:
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcdxHRWzFqAP for <secdir@core3.amsl.com>; Wed, 11 Mar 2009 09:05:39 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 985623A6BAB for <secdir@ietf.org>; Wed, 11 Mar 2009 09:05:38 -0700 (PDT)
Received: from [172.16.2.107] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <SbfhcAA052=B@rufus.isode.com>; Wed, 11 Mar 2009 16:06:12 +0000
Message-ID: <49B7E152.3000004@isode.com>
Date: Wed, 11 Mar 2009 16:05:38 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
References: <085d01c9a21f$0a20afd0$0201a8c0@nsnintra.net> <26116.1236765744.072949@peirce.dave.cridland.net> <090a01c9a258$4cc83220$0201a8c0@nsnintra.net>
In-Reply-To: <090a01c9a258$4cc83220$0201a8c0@nsnintra.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-lemonade-profile-bis@tools.ietf.org, 'Security Area Directorate' <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-lemonade-profile-bis-12.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2009 16:05:41 -0000

Hannes Tschofenig wrote:

>Hi Dave,
>  
>
Hi Hannes,

>Thanks for your quick response.
>  
>
>>>Section 5.7.1 only references another specification where this  
>>>capability is
>>>defined, at least that's my reading. This document only defines a  
>>>profile
>>>and does not require any IANA considerations.
>>>
>>>Here is what Section 5.7.1 says:
>>>
>>>"
>>>5.7.1.  Support for PARTIAL in CATENATE and URLAUTH
>>>
>>>   [IMAP-URL] introduced a new syntactic element for referencing a  
>>>byte
>>>   range of a message/body part.  This is done using the ;PARTIAL=
>>>   field.  If an IMAP server supports PARTIAL in IMAP URL used in
>>>   CATENATE and URLAUTH extensions, then it MUST advertise the URL-
>>>   PARTIAL capability in the CAPABILITY response/response code.
>>>"
>>>      
>>>
>>[IMAP-URL] defines how to construct a URL which references a  
>>byte-range within a body part, and this is newer than CATENATE or  
>>URLAUTH. In particular, IMAP-URL only defines syntax, not protocol,  
>>and doesn't define where the various URL forms can be used at all.
>>
>>CATENATE and URLAUTH are both defined with the assumption that they  
>>only handle URLs without this newer parameter, so the Profile  
>>document defines a new capability to signal that CATENATE and URLAUTH  
>>can be used with byte-range URLs as well as whole-part URLs.
>>
>>So yes, the profile does need to define a new capability not defined  
>>within any of the referenced specifications.
>>
>>I'll have a think about how this can be made clearer - if you've  
>>suggestions, they'd be most welcome.
>>    
>>
>Ok. Now I believe I understood this better. 
>
>
>[IMAP-URL] defines a URL scheme for referencing objects on an IMAP server.
>It does not define how you actually use the URL in order to get the
>referenced objects.
>
Correct.

>In any case, the ABNF for the URL is defined in that
>document and it contains tokens that refer to specifications that are used
>in the IMAP context, for example URLAUTH specified in RFC 4467. As such,
>they define the semantic for these tokens.
>
Right.

>So, now you would like to use the token PARTIAL with the IMAP-URL. There
>isn't really a separate registry of parameters for usage with the IMAP-URL,
>as far as I can tell from my quick read.
>
Correct.

>Section 11 of RFC 5092 only says
>"Elements not defined here can be found in [ABNF], [IMAP4], [IMAPABNF], or
>[URI-GEN]." Hence, this seems to mean that the tokens have to be registered
>in http://www.iana.org/assignments/imap4-capabilities in order to be usable
>for the IMAP-URL.
>  
>
New tokens have to be registered, yes.
What actually happened was that RFC 4469 and RFC 4467 references the old 
IMAP URL RFC (RFC 2192). When the updated IMAP URL (RFC 5092) spec was 
finished, it contained an extra syntactic element - PARTIAL. However in 
order for an IMAP client to know if such token can be used with a 
particular CATENATE/URLAUTH capable servers, a new IMAP capability key 
needs to be advertised by the server.

>Hence, you have to register the URL-PARTIAL token in
>http://www.iana.org/assignments/imap4-capabilities in order to get this to
>work. 
>
>Is this roughly a correct summary? 
>  
>
More or less.

>What section in
>http://tools.ietf.org/html/draft-ietf-lemonade-profile-bis-12 describes the
>semantic of the URL-PARTIAL token? You refer to Section 5.7.1 in the IANA
>consideration section but that section doesn't really say anything in that
>regard.
>  
>
I am not sure what is your concern here. Section 5.7.1 currently says:

   [IMAP-URL] introduced a new syntactic element for referencing a byte
   range of a message/body part.  This is done using the ;PARTIAL=
   field.  If an IMAP server supports PARTIAL in IMAP URL used in
   CATENATE and URLAUTH extensions, then it MUST advertise the URL-
   PARTIAL capability in the CAPABILITY response/response code.

>Btw, maybe you should replace
>"5.7.1. Support for PARTIAL in CATENATE and URLAUTH"
>with 
>"5.7.1. Support for URL-PARTIAL in CATENATE and URLAUTH"
>  
>
The latter is slightly more confusing, IMHO, as one IMAP extension isn't 
typically included in another.
Maybe replace "PARTIAL" with ";PARTIAL=" IMAP URL element"?