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.
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?
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.
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.
o Invent new URI schemes. Ugly as hell.
o Extend existing URI with new invented parameters. Quite a kludge.
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.
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.
Michael