-----Original Message-----
From: Scott Lawrence [mailto:xmlscott(_at_)gmail(_dot_)com]
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf