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

[Alexey Melnikov <[e-mail]>]

Michael Haardt wrote:

>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.
>
In this revision I've just restored the original parameter. I tend to 
agree that it is an overkill, but I think we need to have a discussion 
on list of possible options first.

>  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?
>
I haven't thought about that, but yes, you are right.

One thing that would be awkward, if :method becomes a positional 
argument, is that message content can be a multiline response, followed 
by the method URI. Nothing really wrong with that (string can be either 
quoted or multiline), but this is the first extension where this feature 
can be used for real.

>
>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,
>
Yes. But I think "not cause notifications to be ignored" just follows 
from "MUST be treated as an error". Do you agree?

>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.
>
I think that is overkill. We should stick with one way.
Words are friendlier to humans, but I also like numbers in case we need 
to make relational comparisons on them.

>
>   [[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.
>
My memory is vague on this and the notes didn't record this. Any 
objections from the WG?

>
>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?
>
SHOULD or MAY.

>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.
>  
>
That is fine with me.