> -----Original Message----- > From: Scott Lawrence [mailto:xmlscott@xxxxxxxxx] > Sent: Tuesday, April 06, 2010 2:10 PM > To: Hadriel Kaplan > > On Tue, 2010-04-06 at 13:39 -0400, Hadriel Kaplan wrote: > > This draft says nothing at all about the ordering of the change notice > subscription vs any registration. Oy vey. The more you keep explaining what the draft does NOT specify, the more worried I get. :( > > It's lighter weight because there's no subscription messaging, no > > permanent dialog state, and even the gruu is constructable and does > > not need to be stored by the SSP, only by the UA. > > [sarcasm=on] I don't know why the IETF keeps trying to put state into > > the middle instead of leaving it in the ends! :) [sarcasm=off] > > I'd be open to a fully worked out proposal based on PUBLISH, but I > actually don't think that there are big savings over a SUBSCRIBE based > mechanism. I don't buy the argument that the dialog state is > burdensome - it's a few hundred bytes at most (and much of that size is > under the control of the server). I think we just have to agree to disagree then. If you really think having all UA's SIP-Subscribe, ad infinitum, is not more expensive and error-prone than just sending a single message to it if and only when you need to, then we just live in different Worlds. It's just an informational draft and you don't need to appease me anyway. > I do have some problem with making the notification some kind of side > effect of the 'normal' registration. REGISTER exists to map an AOR to > one or more Contacts. The Configuration Service needs to be able to > address the change notice (whatever method carries it) to a specific UA, > _not_ to the AOR of some user registered to that UA. It's not an AoR, it's a gruu. (or could be... I don't care what form it takes) But it occurs to me I should just shut up and stop trying to argue - my company will probably profit nicely from this draft. ;) -hadriel _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf