Re: WGLC for draft-ietf-sip-subnot-etags-01
Aki Niemi <aki.niemi <at> nokia.com>
2008-03-02 13:42:04 GMT
On pe, 2008-02-29 at 22:08 -0500, ext sip-bounces <at> ietf.org wrote:
> Then that's bad. How does the notifier then know which PIDF to pick in
> presence subscriptions?
>
> Especially if it's not a presence subscription. But seriously, is
> this proposal confined to presence events? I see no such text.
Of course it is not. But clearly presence won't work correctly, if the
notifier doesn't know which URIs route to it, i.e., which resources it
is responsible for. I assume this to be the case for most applications
of SIP events. Can you give an example of a currently specified event
package that doesn't require this?
> In general, a SUBSCRIBE will fork, and the subscriber presumably knows
> how it wants to integrate the events it will receive from the various
> subscriptions, based on the semantics of its situation.
Then presumably the semantics of the situation will also describe how
entity-tags are handled? Especially if they are not all of the same
value in the different dialogs.
> I agree this kind of setup presents a problem. But I also think that
> what we're dealing with here is not that different from the web world.
> There are a lot of load balancing schemes that can be used with HTTP,
> which result in a GET ending up in different data centers in different
> parts of the world at different times.
>
> What's important to note there is that if the service that is accessed
> via this GET needs sessions and gives out cookies, then the backend
> system needs to be synchronized. Otherwise, the servers will be unaware
> of each others cookies, and the service won't work correctly.
>
> Similarly, the backend to the SIP notifiers needs a synchronized
> backend, otherwise, subnot-etags won't work. Naturally, the etags just
> like cookies can be constructed in such a way that they contain the
> necessary state.
>
> There's a hidden philosophical problem: People think of SIP routing
> as being like PSTN routing, where the caller sends the call to a
> number which designates one destination, or at least, a single device
> which has total knowledge of a small number of possible destinations.
> The caller knows the globally-recongized *name* of the
> destination-group, and every destination knows of and is coordinated
> with *every other possible destination*.
>
> Your HTTP model is similar; you assume the request will reach one of a
> set of servers that are co-adminstered.
>
> But the reality is that SIP routing can be like sending e-mail to a
> mailing list -- the sender doesn't know what the possible destinations
> are, and each destination doesn't know what all the destinations are
> either, because some of the routing can be done by agents that are not
> co-administered with either the sender or the destination.
What you are saying is similar to having sip <at> ietf.org route to multiple
mailman instances, each of which has a different set of subscribed email
addresses. But that's not how mailing lists work either.
> Now I think the first case is more common, but if we are going to
> design a general mechanism, it should not fail badly in practice in
> the second case.
Can you give an example event package that would fail badly with
clashing entity-tags and (uncontrolled) forking?
> Getting back to possible solutions:
>
> Looking at section 6.1, I see '[An entity-tag] can have any value,
> except for "*".' (Let's correct that to 'An entity-tag can be any
> token, except for "*".') We can dodge the problem of uncoordinated
> notifiers by demanding that entity-tags have some minimum amount of
> randomness. E.g., if any group of coordinated notifiers picks a
> 64-bit random value, and the entity-tag is generated by making a
> 64-bit hash of that value with the event information, the chances of
> an etag-value collision in any single instance is 2^-64.
Your application of SIP events certainly can implement as much
randomness it wants. But it's hardly appropriate to require that of all
implementations of conditional notification.
For MWI, a timestamp seems sufficient; for conference events, a
monotonically increasing counter would probably work just fine.
> One can easily encode a 64-bit value in 11 token characters using
> (modified) base64. Compare that to the 5-character values used as
> examples in the I-D. Though if we used 6 base64 characters, we would
> still have a 36-bit hash, which is probably good enough.
Were we to design some mandatory-to-implement entity-tag generation
algorithm, I'd much rather suggest salting the hash with appropriately
unique information, like the server IP address and a timestamp, rather
than just "randomness". But since we aren't, this (among many, many
others) is a valid way to generate entity-tags.
Cheers,
Aki
> Dale
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sipping <at> ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip
RSS Feed