Subject: List of issues with Sieve notifications

From: Alexey Melnikov <[email-masked]>
Date: Sat, 15 Oct 2005 16:33:46 +0100

I've incorporated several other changes, the most important are:
1). Clarify that notify doesn't report which actions were taken.
2). Added text about URI validation.
3). Changed priority into a string containing number (currently "1", "2" 
and "3") (Nigel)

Would people prefer to use "high"/"normal"/"low" instead? I though that 
we might want to use relational on the priority, thus it is a number for 
now.

I still have some mailing list messages I need to review, but here is my 
current list of open issues/suggested changes.

1). Need to change the extension name, as there were too many 
incompatible changes.
2). Don't send any notification if no method is given and none 
configured. (Michael)
3). Extend text about URI syntactic/semantic validity. (Michael)
4). Added :from parameter to notify. (Michael)
5). Describe mailto: notification method. (Michael and Ned)
6). Add example about extracting message body. (suggestion from Kjetil)
7). Remove denotify. (many).

I think there is a consensus for doing #7, but I will do it in the next 
revision. I need to rewrite existing examples to make sure that 
variables + notify action are as good as notify + denotify actions. I 
suspect it would be, but I need to do some homework first.

Alexey

---

From: "Nigel Swinson" <[email-masked]>
Date: Mon, 17 Oct 2005 12:25:25 +0100

> 3). Changed priority into a string containing number (currently "1", "2" 

:o)

> Would people prefer to use "high"/"normal"/"low" instead? I though that we 
> might want to use relational on the priority, thus it is a number for now.

I was thinking a number which can be followed by a description.  Then you 
can use i;ascii-numeric comparator to ignore the text if you want to use the 
:value match type.  ie "1 Low", "2", "3 Medium", "8 Uber High" etc.

Which now makes me think we drop it entirely leaving this feature to the 
variables extension, however I guess the reason we have it is not for 
filtering in the Sieve domain, but rather to pass to the notification 
mechanism, in which case the content of this field is very dependant on 
which notification mechanism that is in use.  Perhaps we could use mailto: 
as an example and show this field in use to set the x-priority header?

Nigel

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 17 Oct 2005 13:54:51 +0100

Nigel Swinson wrote:

>> 3). Changed priority into a string containing number (currently "1", 
>> "2" and "3") (Nigel)
>
> :o)
>
>> Would people prefer to use "high"/"normal"/"low" instead? I though 
>> that we might want to use relational on the priority, thus it is a 
>> number for now.
>
> I was thinking a number which can be followed by a description.  Then 
> you can use i;ascii-numeric comparator to ignore the text if you want 
> to use the :value match type.  ie "1 Low", "2", "3 Medium", "8 Uber 
> High" etc.
>
> Which now makes me think we drop it entirely leaving this feature to 
> the variables extension, however I guess the reason we have it is not 
> for filtering in the Sieve domain, but rather to pass to the 
> notification mechanism,

Yes.

> in which case the content of this field is very dependant on which 
> notification mechanism that is in use.

Actually not, the content should be mapped to values expected by the 
notification mechanism.

>   Perhaps we could use mailto: as an example and show this field in 
> use to set the x-priority header?

Sure.

---

From: Michael Haardt <[email-masked]>
Date: Mon, 17 Oct 2005 15:52:34 +0200

On Mon, Oct 17, 2005 at 01:54:51PM +0100, Alexey Melnikov wrote:
> >[priority]

Will we be able to find a single priority value that can be mapped to
all methods and does that suffice? If so, great, but I doubt it.

Exim uses URIs in some places and has the same problem of requiring
additional parameters that are not part of the URI, e.g. authenticated
and timeout parameters for LDAP URIs.  Its solution is to use strings
like:

  "attribute1=value1 attribute2=value2 URI"

Perhaps my suggestion of introducing ":from" was a bad idea and it should
be dropped along with ":priority", adding something like ":attributes",
that passes a string list of attribute-value pairs to the method,
leaving it up to the method definition or even the implementation which
attribute to process:

  notify :attributes ["priority=low","from=sender@domain"] "mailto:0123456789@gateway";

  notify :attributes ["route=immediate","from=0123456789"] "sms:0123456789" ;

The priority attribute may indeed set X-Priority, and even be specified
as such, but I don't see how to map it to SMS.  The gateways I know
offer different routes with names depending on the providers, offering
different service qualities.

Just a suggestion.  So far, I am not real happy either way.

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 17 Oct 2005 16:18:45 +0100

>  notify :attributes ["route=immediate","from=0123456789"] "sms:0123456789" ;
This doesn't make things better, because now we need to standardize 
attribute names.

I would like to have parameters for things that make sense in general. 
Note that this doesn't mean that every notification mechanism must 
support all of them. A notification mechanism can disregard some 
parameters, as long as it is clearly documented.

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 17 Oct 2005 13:52:04 -0400

> This doesn't make things better, because now we need to standardize 

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

I guess an implementation would still be responsible for validating
the elements of a URI, e.g. if standard attribute names are enforced.

mm

---

From: Michael Haardt <[email-masked]>
Date: Mon, 17 Oct 2005 21:00:37 +0200

> 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

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 17 Oct 2005 15:52:00 -0400

> it is a draft and could be changed.

In fact I re-read that draft before making the comments above :-)

> we illustrating their schemes are lacking features or why else don't they

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.

> existing schemes.  I really only like the last, but doubt it is a

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

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 18 Oct 2005 23:15:53 +0200

>    specs sounds very bad to me.

why is putting them in the method spec bad?  adding syntax elements does
mean we need an extension for each method, e.g., require "notify-sms",
but I don't think that is a bad thing at all.  it means the user will
have a way of knowing which notification methods are supported,
something he can't do today.

this would also solve item 1 on Alexey's list ("Need to change the
extension name") :-)
-- 
Kjetil T.

---

From: Michael Haardt <[email-masked]>
Date: Wed, 19 Oct 2005 13:21:25 +0200

> something he can't do today.

Putting options in the method spec is bad, because basically it
introduces overloading.  Suddenly, a parser could not detect
errors on unknown options when parsing the notify arguments, but
first must parse all options, and then semantic analysis has to
find out if there is a signature for them.

Say you have two methods:

"sms", which offers the option "route" to specify the route
"mailto", which offers the option "from" to specify the sender

What's the error message on:

  notify :from "[email-masked]" :method "sms:0123456789" ;

It is: No matching option signature.  Now that's an error users are
really going to hate.

Right now, the only Sieve extension introducing something similar is
"copy".  To me, it looks like nobody thought about what an extension like
that really means, but since it is the only one, everything is fine.
Is it overloading or just an extension? Say I invent a new extension
that introduces another option for fileinto.  If extensions overloaded
the option signature, I couldn't mix it with "copy".  If I could, then
it must not modify the implicit keep flag.  Oops.

The sieve specification contains a small grammar, expressed formally,
and a large semantic part, expressed in natural language.  IMHO, the
latter is the weak part, because it leaves too much freedom.  Please,
let's not open this can of worms.

All this is independent of having to request methods by a Sieve
extensions or not.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 19 Oct 2005 15:28:49 +0200

> It is: No matching option signature.  Now that's an error users are

no, the argument to :method is a structured value, so we can trivially
know that if :method "foo:whatever" exists without a require
"notify-foo", it's an error.  this is similar to the requirements for
comparator.

-- 
Kjetil T.

---

From: Michael Haardt <[email-masked]>
Date: Wed, 19 Oct 2005 15:49:57 +0200

> "notify-foo", it's an error.  this is similar to the requirements for

As I said, insisting on require or not is independent of this issue.
In the example above, assume I requested both the sms and the mailto URI
scheme for notify.  I am not talking about pro or con of using require
to request specific methods, but about why putting syntactic elements
in the method specs is bad:

Looking at the example, the option signature consists of one option only
found in mailto, and the method option found in notify, but with a value
that indicates the sms method should be used.

The user could have meant to use mailto, because he set a :from, but
then typed sms as method.  Or he could have meant sms, but typed from
by mistake.  That's the problem with overloading: You don't select
methods by name, but by signature, and if signatures don't match, you
have no idea what could have been meant.

Putting all possible options in the notify spec, no matter if as syntactic
elements, or as generic attribute-value pairs, solves this problem:
The method decides which options to look at and other options are ignored.
That's a rule users can understand very well.

Michael

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 19 Oct 2005 17:19:03 +0200

> have no idea what could have been meant.

you _do_ select the method by name.  don't try to be smart, use the
scheme the user has named.  if the user makes a typo in the scheme name,
that is no different from any other typo in a Sieve script.

> That's a rule users can understand very well.

no, that's much more confusing.  silently ignoring, say, :from, is not
helpful to the user who wonders why the sender address is wrong ("it
worked with mailto!")
-- 
Kjetil T.

---

From: Michael Haardt <[email-masked]>
Date: Thu, 20 Oct 2005 15:51:30 +0200

> that is no different from any other typo in a Sieve script.

Do you say that the :method option is more important than :from? I
can not justify that, but if we make the :method string mandatory,
things are different.

> helpful to the user who wonders why the sender address is wrong ("it

That's a different issue.  Options not used by a specific method could
be ignored or cause an error.  I tend to agree with you on this, and
if the method is indeed mandatory, the specification would be very easy
to understand.

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Oct 2005 14:43:57 +0100

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

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

>   specs sounds very bad to me.
"option" is "tagged attribute", right?

>   URIs in an invisible way, but does not engrave the option names
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  Extend existing URI with new invented parameters.  Quite a kludge.
How is this different from the next?

>   don't know if that is possible.  Of course it would be very elegant.
Sure, why not.

---

From: Michael Haardt <[email-masked]>
Date: Thu, 20 Oct 2005 16:06:24 +0200

> requirement for Sieve WG documents.

I sent mail to the authors, but did not get an answer so far.  You hit
the point: The draft focuses on interactive applications working on URIs
from untrusted sources.  That scope is too narrow.

> "option" is "tagged attribute", right?

Right.  I should have gotten used to say "tagged attribute" by now. :-/

> be the one true place to locate description of all notification options.

Good idea!

> that script writers would need to know.

Each method spec must tell which URI parameters will be ignored anyway.
The mailto spec will say that the subject and body URI parameters
will be ignored, because notify will set these.  I had no problem on
further saying that the x-priority parameter will be ignored, because
its value is determine from the "priority" attribute-value pair.

And perhaps they should not be ignored, but cause an error if given.
I don't know yet, but that's a different issue.

Yes.

> How is this different from the next?

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.

> >  don't know if that is possible.  Of course it would be very elegant.

Change all concerned URI schemes? The keyword "ivory tower" was already
mentioned.  I favour this approach, but working without a backup strategy
sounds risky.

Michael

---

From: Tony Finch <[email-masked]>
Date: Thu, 20 Oct 2005 15:28:34 +0100

>  notify :attributes ["priority=low","from=sender@domain"] "mailto:0123456789@gateway";

The Cyrus notify implementation (based on an early draft) has :options.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: NORTHEAST 7 TO SEVERE GALE 9. RAIN. MODERATE OR
GOOD.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Oct 2005 15:33:45 +0100

>but almost correct just isn't.
One can write a new draft extending an existing URI scheme.

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

>The keyword "ivory tower" was already

---

From: Michael Haardt <[email-masked]>
Date: Thu, 20 Oct 2005 16:53:45 +0200

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

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 20 Oct 2005 19:30:47 +0100

Michael Haardt wrote:

>scheme name or overall syntax changed.
>
Why? Extensions are the "IETF way".

>Something like Exim's URIs
>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
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.

>about tagged arguments mapped to URI parameters, attribute-value pairs
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.

>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

---

From: Michael Haardt <[email-masked]>
Date: Thu, 20 Oct 2005 23:23:48 +0200

> Why? Extensions are the "IETF way".

Yes, but extensions need to be recognized as such.  Sieve uses "require",
which I like a lot.  URIs start with the scheme, and having two schemes
with the same name, one being a superset of the other, sounds very odd
to me.

> We shouldn't talk about this unless it becomes a problem.

Ok.

> 1). The WG needs to evaluate if mailto: is indeed appropriate.

Up to now, it is.  I have a bad feeling that may change, and gave some
examples of options I don't need, but which would mean a dead end to
URI extension, if I did.

> be mentioned in a Sieve script.

Suppose a SMTP to SMS gateway requires authentication, because it bills
your messages, then you needed ways to specify the credentials and
the gateway host.  But that's just imagination.  All gateways I know
work by having the recipient, not the sender, paying for the message.

Should this turn from imagination to reality, it could look like:

  notify :method "mailto:number@gateway"
         :options ["login=me","secret=geheim","transmission=encrypted"];

Using :options sounds better than :attributes to me.

I am currently building a list of German SMTP->SMS gateways to know better
what exactly they require and offer.

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Oct 2005 14:04:06 +0100

>with the same name, one being a superset of the other, sounds very odd
This is one reason why I suggest to have separate notification method 
profiles. Each profile will define which extensions to a particular URI 
scheme must be supported by the notification method.