Subject: [Simple] Comments received during partial notify WGLC

From: [email-masked]
Date: Fri, 19 Mar 2004 18:06:51 +0200

Hi,

Here is a list of issues that have come up during partial notify last
call. I have included proposed modifications/fixes below. Note that some
small/editorial issues are not included into list below.

1) Tuple ID consistency
PIDF document states in Section 4.1.2 The <tuple> element:
" An 'id' value is
   used by applications processing the presence document to identify the
   corresponding tuple in the previously acquired PRESENCE INFORMATION
   of the same PRESENTITY"

My own understading on the text above is that tuple ids should be
consistent for same tuples. However, text above doesn't seems to be
normative and partial notify mechanism requires this functionality to
work. I have added following text into partial-notify draft:
"   Tuple ids are used to identify if tuples are same between subsequent
   notifications or not. Notifier MUST use same tuple ids for tuples
   which are identical between subsequent notifications and different
   tuple ids for tuples which are different from previously send tuples.
   Tuple ids MUST be consistent until next full state presence document
   is delivered. Decision  whether  tuples are same or different is up
   to notifier's local policy.
"
Personally I think that ids should be consistent between two full
presence document. This is because watcher must drop all previously
received presence info when new full state presence document arrives.

2) Unique Tuple Ids
I have added text saying that all tuple ids must be unique in the
presence document. This means tuple ids in <tuple> elements and in
<t_id> elements.

3) Use of 'applicatio/pidf-partial+xml' for initial notification
It was commented that 'application/pidf+xml' could be used for initial
notify. This might be possible but my own view on this is that it might
be easier for watcher to learn from initial notify if notifier is going
to send partial notification or not. I have added text saying that
notifier must not include <remove> element when "state" is "full" and
watcher must ignore <removed> elements if they appear in the presence
document with "state"  "full".

4) Receiving notification having old "version" numbers
Last call version contained text:
"If the watcher receives a notification with the "state"
   attribute's value "partial" and the "version" attribute's value is
   equal or smaller than the one in the previous notification, it is
   considered a PS failure and the watcher SHOULD either refresh or
   terminate the subscription.

These old versions actually cannot corrupt the local presence document
and so it should be necessary to resubscribe or terminate the
subscription. I have changed this to:
"If the watcher
   receives a notification with the "state" attribute's value "partial"
   and the "version" attribute's value is equal or smaller than the one
   in the previous notification, it is considered a notifier failure and
   the watcher SHOULD discard the document without processing."

5) How much text should be copied from presence event package
There has been some confusion how to handle subscription refreshes and
terminations. I have added text saying that notifier must always respond
to subscribe requests with full presence document. Same applies when
notifier terminates the subscription.

6) XML schema
XML schema redefined also "entity" attribute. This isn't necessary and
its now removed. 

7) Examples
<removed> element appeared before <tuple> elements in the examples. This
was incorrect and now all <tuple> element come before <removed>

8) examples
"version" started from wrong value in all examples. Versions start now
from 0.

9) partial PIDF section 4, last bullet
"The presence
      document MUST only contain tuples which have changed compared to
      last time the presence document was delivered i.e. it must contain
      new tuples and modified tuples."
MUST has been changed to SHOULD

- Mikko