On Thu, Oct 20, 2005 at 02:43:57PM +0100, Alexey Melnikov wrote:
draft-duerst-mailto-bis-00 (expired?) extends RFC 2368 and says:
4. Unsafe Headers
The user agent interpreting a mailto URI SHOULD choose not to create
a message if any of the headers are considered dangerous; it may also
choose to create a message with only a subset of the headers given in
the URI. Only the Subject, Keywords, and Body headers are believed
to be both safe and useful.
The creator of a mailto URI cannot expect the resolver of a URI to
understand more than the "subject" and "body" headers.
Ok, again a draft, but successor of a RFC. Obviously, "from" and
"x-priority" are not considered safe, yet we would like to use them.
Different application of URIs have different needs. We can amend this
requirement for Sieve WG documents.
I sent mail to the authors, but did not get an answer so far. You hit
the point: The draft focuses on interactive applications working on URIs
from untrusted sources. That scope is too narrow.
o Invent new generic options that cover all methods and each method
picks the options it understands and ignores the rest. This extends
URIs in an invisible way, but having the options in the notify spec
is a problem if a new scheme needs more. Putting them in the method
specs sounds very bad to me.
"option" is "tagged attribute", right?
Right. I should have gotten used to say "tagged attribute" by now. :-/
o Pass generic attribute-value pairs to methods, and each method
picks the options it understands and ignores the rest. This extends
URIs in an invisible way, but does not engrave the option names
in rock.
If we do that, we should create a new IANA registry, which is going to
be the one true place to locate description of all notification options.
Good idea!
One good thing about standardized attribute-value pairs is that they
might be more readable to people than an URI parameter.
So if we have "priority=high", it might be representable in both mailto:
and XMPP (frankly I don't know that it is true to XMPP URI, but let's
assume for a moment that it is) URIs, but it will have different syntax
that script writers would need to know.
Each method spec must tell which URI parameters will be ignored anyway.
The mailto spec will say that the subject and body URI parameters
will be ignored, because notify will set these. I had no problem on
further saying that the x-priority parameter will be ignored, because
its value is determine from the "priority" attribute-value pair.
And perhaps they should not be ignored, but cause an error if given.
I don't know yet, but that's a different issue.
So effectively attribute-value pairs would extend and/or override URI
parameters.
Yes.
o Invent new URI schemes. Ugly as hell.
o Extend existing URI with new invented parameters. Quite a kludge.
How is this different from the next?
If I simply let notify understand SMS URIs with the parameter "route",
the URI will violate the officially specified URI definition. Possible,
but almost correct just isn't.
o Try to officially extend the URI schemes by parameters we need. I
don't know if that is possible. Of course it would be very elegant.
Sure, why not.
Change all concerned URI schemes? The keyword "ivory tower" was already
mentioned. I favour this approach, but working without a backup strategy
sounds risky.
Michael