Message-ID: <493EB5EB.2040208@isode.com>
Date: Tue, 09 Dec 2008 18:16:11 +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
To: Aaron Stone <aaron@serendipity.cx>
CC: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=
 <Dilyan.Palauzov@aegee.org>, IETF Sieve WG <ietf-mta-filters@imc.org>
Subject: Re: managesieve: formats; :global; read-only; checkscript
References: <49271D09.90408@aegee.org> <492C63F2.9030509@isode.com>
 <4932D45C.2050203@isode.com> <1228509838.16036.21.camel@turtle>
In-Reply-To: <1228509838.16036.21.camel@turtle>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk


Aaron Stone wrote:

>On Sun, 2008-11-30 at 17:58 +0000, Alexey Melnikov wrote:
>  
>
>>>>My suggestion is to let the user see the global scripts, when the 
>>>>authorization ID is the empty string.  In terms of the Sieve URL 
>>>>Scheme, the global scripts could be accessible when owner = '\0'.  I 
>>>>mean when
>>>>         sieveurl-script = "sieve://" [ authority ] "/"
>>>>                           [owner "/"] scriptname
>>>>has the form
>>>>         sieveurl-script = "sieve://" [ authority ] "//" scriptname
>>>>then requested are the global scripts.
>>>>        
>>>>
>>>While I think having a standardized way of accessing global scripts 
>>>would be a good idea, I am not convinced that the empty string is 
>>>going to be Ok.
>>>This might have some weird side effects on URI parsers (but I am not 
>>>sure).      
>>>
>Some URI parsers will collapse repeated slashes, some won't. I've seen
>weird behavior before when slashes were duplicated in HTTP requests and
>a non-collapsing URI parser was in place. Is there a "correct"
>normative behavior for this?
>
I think handling of repeated slashes in URIs is URI-scheme specific. 
(The behavior you describe is quite sensible for HTTP, because 
filesystems convert "//" to "/".)
The only rule is that if a URI scheme allows for relative path URIs, 
they can't start with unencoded "//", as this would be indistinguishable 
from URI's "authority" component (username + host + port).

In "sieve:" URIs I've prohibited relative path form, so that shouldn't 
be an issue.

>Aaron  
>
>>I've updated the draft to include your proposal. It looks like "owner" 
>>can be empty, as long as "authority" is not.
>>    
>>