Subject: [Simple] Belated wglc comments on partial notify

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Mar 2004 11:41:41 -0600

Sorry for the belated comments.

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.

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.

And a few nits and small issues:

partial-notify:

4.1: Add another citation to the format document.

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

4.4 Inconsistent use of PS and notifier.

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.

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?

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: .."

partial-pdif-format:

Section 1, p2 "in <tuple> level" --> "at the <tuple> level"

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.)

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.

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.

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Mar 2004 11:41:41 -0600

partial-notify:

partial-pdif-format: