Re: I-D ACTION:draft-ietf-sieve-notify-03.txt

[Michael Haardt <[e-mail]>]

Hello,

I am just changing my code to implement -03 and have a few issues:

Section 3.1:

  [":options" 1*(string-list / number)]

Honestly, I think that's overkill.  An arbitrary amount of string lists
and numbers, but it must not be empty? I expected a single string list
and I am surprised to see it was considered not to be enough.

This has the implication that the ":method" tag is going to stay forever,
whereas I expected -03 to remove it, making the method string the last
argument.  Correct?

Section 3.2:

   An implementation MAY enforce other
   semantic restrictions on URIs -- for example an SMS URI can only
   contain phone numbers in a particular geographical region.  Violation
   of such semantic restrictions MUST be treated as an error.
   [[Barry 1: "MUST" seems silly here, since the whole sentence is a
   "MAY".]]

How about wording it differently?

   An implementation MAY enforce other
   semantic restrictions on URIs -- for example an SMS URI can only
   contain phone numbers in a particular geographical region.
   A violation of such semantic restrictions MUST be treated as an error
   and not cause notifications to be ignored.

If that is not what was meant, then I guess we should word it differently
for sure. :)

Section 3.5:

   [[Alexey 1: Should we keep using "high", "normal" and "low" instead?
   Numbers are easier to compare with comparators.]]

Since we talk about an input parameter to "notify", how about allowing
words as well as numbers? Expressions using variables might generate
numbers, whereas users probably prefer words.

   [[Barry 3.5: Why do we call this "priority", and then explain it as
   "importance"?  Shouldn't we just call it "importance"?]]

YES. In fact I thought it was decided to change that in -03.

Section 3.6:

   If the message parameter is absent, a default message
   containing the value of the From header field [[Alexey 3: Align with
   usage of :from]] and the value of the Subject header field will be
   used.  Note that the notification method (the ":method" tag) may
   affect how this information is formatted.

Is that a suggestion, a MAY, SHOULD or MUST? Sites should be free to
send other default messages and I vote for:

   If the message parameter is absent, a site-specific default message
   will be used.  It is suggested that it contains the value of the
   "From" header field and the value of the "Subject" header field.

Michael