On Oct 12, 2007, at 11:32 AM, Brian Stucker wrote:
I'm missing something here.
When I send a SUBSCRIBE I'm saying the following, "For the resource
identified by the request-URI, I'd like to synchronize with a
particular
state machine for X seconds with the state data encoded in format Y."
The other end can accept or reject the request as a whole, there is no
offer/answer negotiation going on.
Mostly. Except that you're ALSO saying "And I expect the data
transmitted to me as a result of this subscription to have the
meaning (aka semantic) specified by the specific event package named
in the subscription." That's more than saying "Please send me jpeg
images".
And with Francois' proposal, you're saying that you'd like to
synchronize with that same state machine, as it applies to the
current dialog, for the duration of the current dialog, with the
state data encoded as indicated by the event package and to have the
meaning specified by the event package.
If we were to trigger a subscription based upon the INVITE that takes
care of targeting the resource and the duration of interest and leaves
out identifying the particular state machine you want to synchronize
with and how you want to encode the state data.
Huh? No you still have to say which event package you're talking about.
Can't I identify the state machine I want to synchronize with using a
supported header and the encoding using the accept header, specifying
the pair-values that are legal in an IETF document? Isn't this what
RFC-3312 did, and although integrated differently into the protocol
because the state machine being synchronized was SIP itself what
RFC-3262 does?
Not quite sure of the relationship to 3312. It seems to me that RFC
3312 negotiates a fixed set of preconditions with explicit values,
whereas INFO (and events) encompasses a much broader range. That's
why RFC 3265 adds the event-package name and registry process.
-_
Dean
_______________________________________________
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
