[Top] [All Lists]

Re: Proposal to change sieve: URL syntax used by the ManageSieve protocol

2008-10-11 13:01:59

Kjetil Torgrim Homme wrote:

On Sun, 2008-09-21 at 12:55 +0100, Alexey Melnikov wrote:
Chris Newman has reviewed the ManageSieve document and sent me the following comment on Sieve URLs that point to scripts:

Section 3:

       sieveurl-script = "sieve://" [ authority ] "/" scriptname
* IMAP URLs made the mistake of confusing the identity used to authenticate with the identity that owns the script. This makes IMAP URLs cumbersome. I would strongly encourage a naming model that separates the two and keeps the script owner explicit. For example:

 sieveurl-script = "sieve://" [ authority ] "/" owner "/" scriptname
I agree with Chris, however I am concerned that there are existing applications using <sieveurl-script> form of Sieve URLs.
So I would like to hear from people:
1). opinions on whether you think this change is a good or a bad idea

it might be a good change.  the URI specification as I read it does not
mandate changes to the userinfo to indicate separate namespaces, but
it's clearly allowable.  if we put authentication credentials in the
"authority" (e.g., authz "=" auth ":" password "@" server), this will
too create a new namespace...
Hmm, this is something that no other URI scheme does. So I would rather avoid creating a separate syntax.

oh -- I think the ManageSieve specification should disallow encoding the
password as part of the URI,

As far as I remember the base URI document has already prohibited this feature, so I don't think we need to worry about this.

or it needs to go the whole hog and specify how to encode SASL methods, the 
need for TLS etc.

IMAP URI document did this. I am a big believer in negotiating the best security using SASL and TLS, so I don't think there is any benefit.
Certainly not for SASL mechanisms.

to make the owner an explicit part of the path itself is a clean and
intuitively understandable solution, especially for listscripts when the
user is authorised to edit the scripts of many owners.  the other
alternative is to make it crystal clear that the userinfo component in
authority indicates the owner, and authorization by other parties can
not be encoded in the URI.

<Prev in Thread] Current Thread [Next in Thread>