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.