I've just noticed that "status" is not registered in the IANA Considerations
section.
Geez, how'd I miss that?
I've added it to my working copy. We can put it in as an RFC-ed note,
or I can submit a new version at the appropriate time.
The "online" notification capability used the value "maybe" instead of
"unknown". I know that this is awkward, but should we be using the same
value for consistency?
I think not. It could make sense to use "maybe" for "busy", but
definitely not for "show". Too bad about "online". :-)
This document defines a set of items of notification presence, which
may be specified in the notification-capability parameter. The
script tests the values of notification presence items in the key-
list parameter. The values that each item may have are specified in
the list below; Note that in addition to the presence values, any
item may have the value "unknown" if it is not possible to determine
the correct presence value of the item.
Does this mean that the "status" notification item can also have a value
"unknown" if it is not possible to determine it?
As I replied to Tony:
After status definition, add
unknown - The correct availability status could not be determined.
I thought about that, but I don't think I like it. This is a
human-readable field, and it's made clear that it's not for automated
processing. It's plain text, most likely set by the user, and it
could be anything, including "unknown". I don't want to try to
*reserve* the value "unknown" in any way -- we can't, anyway; we have
no control of it.
I'd prefer to leave things as they are, and if an implementation wants
to infer that it can stick in "unknown", that's fine. The reality is
that we're clear that this is for human consumption, and *any* value
that's put in there could also be put there by the human.
If you think that's confusing, and want me to put explicit text saying
that there's no way to indicate that the value of this is not known, I
can do so. I don't think it'll be an issue, in practice. I'm also
not averse to changing the text. Either way.
Barry
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve