=======
notify-presence
The value of "unknown" should be explicity listed in section 2 for each
item that can return that value, rather than being mentioned in passing
at the end of section 2.
I don't agree; "unknown" isn't a value of the presence, but an
artifact of retrieving it; I think it's worth keeping that separate.
Would you be happier (I think I would) if I moved it up? My working
copy now has this as the second paragraph, just before the list:
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; in addition, any item may have the value "unknown",
if it is not possible to determine the correct value of the item.
I think it would be worth putting a note in somewhere that an
implementation may wish to cache the results of a call to
notify_method_capability so that if it is used in a series of if/else
tests, it only needs to be retrieved once.
Now that you bring this up, I'm tempted to go even further, and say that any
result should be consistent throughout the script. If statuses change and
notify_method_capability returns inconsistent results at different times in
the same script, I could see that causing some unpleasant results.
I like Ned's suggestion, and I will add that. My working copy now has
this as the third paragraph, just before the list:
If a particular presence item is tested multiple times within the
same script execution context, implementations MUST present the same
value each time (for example, by caching the value on first use).
This provides consistency within a single execution.
Please let me know if you guys are happy with these changes, and I'll
post a revision.
Barry
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve