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.