On Mon, Oct 17, 2005 at 09:00:37PM +0200, 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.
In fact I re-read that draft before making the comments above :-)
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?
My thinking was that if you need to convey some parameters to a
notification system, the things that you might want to convey ought to
be able to be specified in a URI for the method used by that system.
You've illustrated why that's an ivory-tower kind of approach, though.
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.
So the dilemma is that even if the URI ought to be the place to put
parameters (which I am inclined to think it is), we can't just go making
up non-standard URI elements. (I am not in favor of inventing new
unofficial schemes or parameters either.) Your :attributes idea is an
interesting technique to amend URIs in ways that have yet to be
standardized or even yet thought of, but one problem is that it can
become a free-for-all, with each implementation inventing its own
attribute names, and having to maintain support for them forever. As
Alexey said, "now we have to standardize attribute names" to lessen the
impact of that. And then at some point when some parameter makes its way
into a standardized URI syntax, more confusion will ensue. (Of course
your #1 item has these problems too.)
The #1 and #2 items in your list are functionally equivalent, except
that #1 requires an RFC cycle to extend the tagged option set, whereas
#2 only requires a keyword registration (assuming that it's agreed that
registration is a good idea). So :attributes is looking better to me
from that point of view.
mm