Hello,
Again about "include :global" and authorization ID.
draft-ietf-sieve-managesieve-03, Section 3. Sieve URL Scheme defines
sieveurl = sieveurl-server / sieveurl-list-scripts /
sieveurl-script
sieveurl-server = "sieve://" authority
sieveurl-list-scripts = "sieve://" authority ["/"]
sieveurl-script = "sieve://" authority "/"
[owner "/"] scriptname
[owner "/"] in sieveurl-scrupt provides the possibility to edit the
scripts of the other users, but sieveurl-list-scripts cannot show how
are the scripts of that users named. What about including [owner "/"]
in sieveurl-list-scripts, making it to:
sieveurl-list-scripts = "sieve://" authority ["/"] [owner "/"]
In this way one can see a list of scripts, that are managed by other users.
Със здраве,
Дилян
Alexey Melnikov wrote:
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.