Subject: [Simple] RE: Belated wglc comments on partial notify

From: [email-masked]
Date: Mon, 15 Mar 2004 21:09:27 +0200

Hi,

> 
> Sorry for the belated comments.

Thanks for comments in any case. They came just in time

> First, a couple of general comments. I vaguely recall
> discussing these 
> before, so apologies if the are already resolved.
> This entire concept depends on the idea that tuple ids will be 
> consistent between one notify and another. I'm not sure if we 
> can count 
> on that. Is that a normative requirement anywhere in the presence of 
> pidf specs? If not, then there is really no way to say that 
> two tuples 
> in two different docs are the "same" tuple.  If this is not required 
> elsewhere, then we must make it a requirement to support partial.

Yes, the mechanism requires that notifier keeps same tuple id for
identical tuples. PIDF says: "The <tuple> element MUST contain an 'id'
attribute which is used to
   distinguish this tuple from other tuples in the same PRESENTITY.  The
   value of an 'id' attribute MUST be unique within 'id' attribute
   values of other tuples for the same PRESENTITY.  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.  The value of the 'id' attribute is an
   arbitrary string, and has no significance beyond providing a means to
distinguish <tuple> values, as noted above."

I would read text above to mean that tuple ids must be consistent. If
text above does not mean that then this needs to be added to partial
notify drafts. I think that in any case this could be made clearer in
partial notify drafts.

> Why use partial format for full state notifies rather than the basic
> pidf format? Doing that allows you to do things like put <removed> 
> elements in an initial notify. Do we want to allow that? If 
> so, we need 
> text to say what it means. If we were to use the basic format 
> for full 
> state, then the whole state attribute would no longer be needed.

The intention is definitely not to allow <removed> in initial notify.
Using PIDF for initial notification might be possible but I am not sure.
My own thinking about this is that for watchers it is easier to learn
already from initial notify if notifier is going to send partial
notifies or not. My proposal would be to add text which says that adding
<removed> element into initial notification is not allowed. 
 
> 
> And a few nits and small issues:
> 
> partial-notify:
> 
> 4.1: Add another citation to the format document.

Will add

> 4.4 Paragraph 1 is redundant with 4.3, and not quite
> consistent with it.

Right, I will remove paragraph 1 from 4.4

> 4.4 Inconsistent use of PS and notifier.

Yes, fixed.

> Recovering from a missed notify depends on the notifier
> always sending 
> full state after a subscription refresh. Where is this behavior 
> mandated? 4.4 says you have to do this on the first notify, 
> but does not 
> mention refreshes.

Yes, I have added text to explain this. 

> You say that if a watcher gets an old version number, it
> SHOULD refresh 
> or terminate. What else could it safely do? Is SHOULD strong enough?

Actually I was planning to modify this so that watcher ignores
notifications with old version numbers. Watcher can safely do this and
it is consistent with winfo. I think refresh doesn't help here. Watcher
could also terminate the subscription but I am not sure if we should
document every possible recovery option from error condition? 

> Examples: Use real content-lengths, or something that clearly
> indicates 
> you would replace the content-length with something real. I 
> fully expect 
> to see an implementation include "Content-Length: .."

Ok, if you see that there is real danger some implementation would send
...

> partial-pdif-format:
> 
> Section 1, p2 "in <tuple> level" --> "at the <tuple> level"

ok

> Section 3: I think there is  lot more to implementing partial than
> defining a new mime type. I think you want to say that implementing 
> partial _requires_ defining a new mime type. (It's a sufficient 
> condition vs necessary condition distinction.)

Yes, that was the intention. I will modify accordingly.

> Section 4, second bullet: MUST strength may be a little
> strong here, as 
> it does not damage to include an unchanged tuple; it is merely less 
> efficient. Further, a watcher definitely should not be in the 
> business 
> of rejecting a notify because it contained an unchanged tuple.

Right, I will change that to SHOULD

> 5.1: security considerations: Can we get away with just requiring
> appropriate precautions? Better to reference the security 
> consideration 
> section, which may then say the issues are identical to those 
> for PDIF.

Strange, I though I had already added that. Will go into next version.

- Mikko

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple