[Top] [All Lists]

Re: [sieve] AD review of draft-ietf-sieve-notify-presence-02.txt

2010-10-25 17:43:44
I've just noticed that "status" is not registered in the IANA Considerations

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.

sieve mailing list

<Prev in Thread] Current Thread [Next in Thread>