Michael Haardt wrote:
On Mon, Oct 17, 2005 at 01:52:04PM -0400, Mark E. Mallett wrote:
I kind of like ":from" but it seems to me that something like
:attributes, to pass specific information to a particular notification
method, would be covered by the URI format for that method. The
standardization of attribute names (if any) would be done at the URI
encoding level. (If a URI has not been standardized for a specific
method, corresponding attribute names wouldn't have been, either.)
Do you suggest to invent new URI schemes?
draft-wilde-sms-uri-10 does not allow to specify a sender or a specific
route. Sure, mobile phones don't allow that, but gateways do. I realize
it is a draft and could be changed.
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.
Are we abusing URIs to perform something they were not made for, are
we illustrating their schemes are lacking features or why else don't they
fit?
Just a general note than many URI types don't have many features
supported by the protocol, two examples are HTTP and IMAP.
For example HTTP doesn't have a way to specify HTTP method, i.e.
POST/GET/PUT/etc.
I see a bunch possible approaches:
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?
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.
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.
So effectively attribute-value pairs would extend and/or override URI
parameters.
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?
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.
As a matter of fact, we need to pass data that can't be passed through
existing schemes. I really only like the last, but doubt it is a
solution.