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.
One can write a new draft extending an existing URI scheme.
If I were to review such a draft, I would not accept it, unless the
scheme name or overall syntax changed. Something like Exim's URIs
that begin with attribute-value pairs, separated by white space
and followed by the URI is fine.
If the editor of an URI scheme refuses to change it, or if the revision
process takes too long, I think that should be accepted and ways to pass
information not in, but next to the URI, should be chosen.
Change all concerned URI schemes?
So far we've identified only 3, I don't think it would be too hard. I
don't think anybody is proposing to examine all standardized URI types.
I have little to no experience in that area. If you think changing xmpp
(sp?), sms and mailto could be changed, I am more than willing to forget
about tagged arguments mapped to URI parameters, attribute-value pairs
and the like.
Changing the mailto URI is troublesome, because it contains one namespace
for both headers and other parameters. If someone introduced a new header
field called "Body", it would fail badly. You can't specify credentials,
message transmission modes or even the smart host to use, and you can't
add any of that, because it would conflict with header names. Up to
now, all I have trouble with are the security considerations and their
consequences. Should that ever change and new parameters are required,
that route is a dead end.
Michael