> -----Original Message----- > From: Robert Sparks [mailto:[EMAIL PROTECTED] > Sent: Friday, October 26, 2007 2:48 PM > To: Francois Audet > Cc: Sanjay Sinha (sanjsinh); sip List; Adam Roach; Dean Willis > Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for > direction. > > So, the thing we're talking about then is not a subscription. > (You will not use the same code to service it that you would have > used to service a subcription).
Right, I think several of us have said it's not a subscription in the 3265 sense of the word (and it's probably less confusing if we don't use the word "subscription" at all). > And if you accept that the fates are tightly coupled (as I think you > are asserting here), then we > _don't_ have separate usages that spring into being and disappear at > the same time. There's only > one usage - the INVITE usage. Precisely. Exactly how INFO was used before. > And forgive me for continuing to point, but are you going to address > the authorization mechanics and if not, what are the simplifying > assumptions that let us ignore them. Actually I think it's clearer for this mechanism than it is for Subscriptions. With Subscribe, I don't see how an Invite-generating UAC can truly authorize a subscriber as the UAS. It's clear how a server offering a subscription service such as presence can do it, because the server should know which UA's can subscribe to its service, and can challenge them knowing the user password or whatever. But how does my phone know any shared secret with which to challenge some random entity subscribing to KPML for an Invite dialog? With this inline INFO mechanism, it would be based on the Invite. If the UAC sent the Invite with the send/recv event headers, it's authorizing the receiver of the Invite to send/recv them. If the UAS wants to accept the events, it responds with such headers. The INFO message would be handled the same way as re-Invites would, with regard to their acceptance. -hadriel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
