> -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 11, 2007 2:32 PM > To: Audet, Francois (SC100:3055) > Cc: IETF SIP List; Christer Holmberg > Subject: [Sip] Francois' counter to INFO (was Re: What are we > arguing about when we say INFO?) > > > On Oct 11, 2007, at 11:55 AM, Francois Audet wrote: > > > Hi Dean, > > > > Can you tell me what is the difference between > "contextually-adapted > > INFO", and a "subscription embedded in the INVITE, with the NOTIFY > > using the same dialog"? I don't see any advantage to the INFO > > approach. > > > > One might argue that the second is a means of implementing the first. > > INFO, as written, lacks contextual negotiation. You're > proposing to replace the method name with NOTIFY and use the > event-package framework for content and context expression, > using a header-field in the INVITE request to engage context > negotiation. It seems to me like that would work. There's > nothing "implicit" about it, and it is no worse for overhead > than using Supported or Allow. It also has the advantage of > letting us reuse an existing registration framework, IANA > process, and specification review process under RFC 3427. > Very tidy, I think I like it.
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. 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. 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? Regards, Brian _______________________________________________ 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
