[Top] [All Lists]

Re: List of issues with Sieve notifications

2005-10-20 11:59:12

Michael Haardt wrote:

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.

Why? Extensions are the "IETF way".

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,

I am not sure if you are talking about editor having good reasons for saying "no" or just being an asshole. Unless the draft has "no derivative work" IPR statement, the editor doesn't have total control over the document and other people can publish independent documents based on 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.
You are trying to work around process issues by using different syntax. I think such approach is wrong.
We shouldn't talk about this unless it becomes a problem.

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.
I can't give any general case answer to this question unless I see a list of desired options. But in general I see no problems with extending URI syntaxes.

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.

Two comments:
1). The WG needs to evaluate if mailto: is indeed appropriate.
2). credentials, message transmission modes and submission server host seem like a configuration issue (unless you want each user to authenticate as the receiver of the message), I don't think they should be mentioned in a Sieve script.

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.