[Top] [All Lists]

Re: List of issues with Sieve notifications

2005-10-20 07:14:53

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
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