On ma, 2007-10-08 at 17:02 +0200, ext Avshalom Houri wrote:
>
> Several comments:
>
> -------------
> A possible security issue with the following scenario:
> a) Subscriber subscribes with Suppress-Body-If-Match
header with
> etag of e1.
> b) The document has changed but what was changed is
suppressed from
> that subscriber due to privacy.
> c) The subscriber will get notify with new tag but with
the same
> document.
>
> If the subscriber wants to it can compare to the
previous value and
> understand that something is being suppressed from it.
I think this is an implementation issue. But really, the
notifier
shouldn't be generating a new entity-tag, if the entity
hasn't changed.
I think the model already talks about this. A resource can
have several
*different* representations, each of which also has its own
private pool
of entity-tags.
> -------------
> Section 5.2 - second paragraph
> "the first notification after the SUBSCRIBE"
sounds as the first new
> notification due to state change after the SUBSCRIBE.
Maybe it is
> better
> to write "the immediate notification following the
SUBSCRIBE".
> Note that there are other occurrences of the usage of
"first" if you
> decide to change.
This is fixed in -02. Now, the condition applies to all
subsequent
notifications.
> -------------
> Section 5.2 - Last paragraph before the examples
> typo - "simply copies" should be
"simply copied"
No I really meant copies. I guess this could be said
differently, but I
like my way better. ;)
> -------------
> Section 5.2 - last example
>
> Maybe there should be some explanation of why * is
needed earlier
> in the document. Liveliness use case is described below
but maybe
> better to explain earlier in the doc
The wildcard is better motivated now, I think.
> -------------
> Figure 4
> ... poll interval elapses
>
> Should probably be "... poll interval elapses
immediately"
> Since it is zero initially.
No, it's not zero; the expires is zero because it's a
"fetch". The poll
interval is the time between successive fetches. That can be
anything
the subscriber wants.
> Section 5.6
> Should not this be the first use case described? From
bandwidth pov
> it is the most important.
Well, these are not in priority order.
> -------------
> Section 6.1
>
> "
> ...The notifier MUST remember the entity-tag of an
entity as long
> as the version of the entity is current. The
notifier MAY
> remember
> the entity-tag longer than this, e.g., for
implementing journaled
> state differentials (Section 6.4).
> "
>
> I understood from the text that the etag can be deleted
by the
> notifier
> when there is no current value to the entity. Consider
the case when
> a subscriber subscribed and got entity e1. Meanwhile
the resource has
> become
> stale (all previous publishes expired).
This would cause the entity to change, no?
> After e.g. two days the subscriber tries to subscribe
with e1 for
> the suppressing condition. What will the notifier
selecting e1 as the
> current entity tag again? If it does so the subscriber
will not get
> a notify (or body of notify) while it should have
gotten one.
> I hope that this is only my misunderstanding.
It should get a new NOTIFY that reports the latest state.
> -------------
> Comment from Ofira Tal (IBM)
>
> Should we consider the change of the entity tag as a
reason to
> send a notify with the entity tag only even though
there is no
> need to send an actual notify to the subscriber since
the change
> affects filtered information due to privacy or just
filtering.
> This will enable avoiding redundant NOTIFY in
subsequent
> subscribes since the latest entity tag will be used.
The model tries to take privacy filtering into account with
the concept
of representations. In effect, each possible variation of
the resource
state due to privacy filters being applied and whatnot, is a
unique
representation that has it's own entity-tag pool.
Notifications are only
generated for this representation, when actual reportable
changes
trickle through the filters. At this point, a new entity-tag
would be
generated as well.
If the model isn't clear on this, I'm open to suggestions.
Thanks for the review!
Cheers,
Aki
> --Avshalom
>
>
>
>
_______________________________________________
Sip mailing list http://www.i
etf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
