1. INFO for keep alive? That¹s a new one. Everyone I know uses OPTIONS. Oh well. Maybe we should resurrect the PING method.
2. INVITE discussion is a non-sequitur. INVITE fully specifies a negotiation framework. INVITE without SDP is an invitation for you to start the negotiation. 3. The semantics of the media are totally orthogonal to the INVITE negotiation. C.f. the LONG discussion on P-Asserted-Service. 4. The semantics of an INFO body is critical. The stack needs to know how to process the body or where to pass the message to. Right now, there is no mechanism for doing that. Content-type does not work. 5. "Just write it down": Agreed, and there has already been a framework for doing INFO negotiation (Dean's document). I was about to go there, until I realized that it would be identical to SUB/NOT. 6. Rough work group consensus was NOT to create an INFO negotiation mechanism. If you can convince the chairs otherwise, I'd be happy to submit a negotiation mechanism. 7. The argument that we have to extend INFO to do negotiation because we need to protect the existing INFO-based DTMF implementations is totally bogus. If we create a negotiation mechanism, those existing implementations have to be fixed. If they have to be fixed, any reason not to fix them with something that already works and won't suck down work group and RFC Editor time? 8. Who in their right mind would use KPML for keep alive? You can always subscribe to anything with an expires of zero. It is still silly in any event [sic]. On 9/10/07 11:46 AM, "Brian Stucker" <[EMAIL PROTECTED]> wrote: > > >> -----Original Message----- >> From: Eric Burger [mailto:[EMAIL PROTECTED] >> Sent: Monday, September 10, 2007 8:08 AM >> To: Stucker, Brian (RICH1:AR00) >> Cc: [email protected] >> Subject: Re: [Sip] INFO >> >> Brian Stucker Says: >> I'm not really sure what your point was >> here unless you are against people >> writing down a common way of using >> a protocol amongst themselves >> >> Actually, I have no problem with "people writing down a >> common way of using a protocol". One would offer that is the >> work of the IETF. However, the key phrase I have a problem >> with is, "amongst themselves." The IETF makes protocols for >> everybody, not just members of the garden club. The garden >> club can do whatever they want inside their garden. The IETF >> has no right nor interest in mandating what goes on inside >> their garden. > > True, but it's not a club. Those disclaimers are to limit reproduction > of the material by other SDOs without permission. You don't have to be a > member of the garden club to use the protocols written by the garden > club, such as they are. Whether you want to or not is another matter > entirely. > > [SNIP] > >> In my mind, INFO for DTMF falls into the, "it is not an >> Internet protocol, but you can do whatever you want in your >> playground, so long as your fences are good and you will >> still play with me. P.S., do not claim you are using Internet >> protocols, because you are not." > > Only because they happen to not be written down as an IETF document, > which, as I suggested earlier, may be the solution to the problem. > >> >> P-Preferred-Service is an example of something that falls >> into "the toxic substance that will bleed through, so do not >> even think of using it" category. > > So then I would be most interested to hear your thoughts on the > following: > > The first sentence in section 2 in your draft states: > > "There is no programmatic way of determining what the content of > an INFO request means." > > You could say the same is true for an INVITE. To the 'User-Agent's point > of view, an [INVITE] just appears'. Without a negotiation mechanism such > as SDP, is this INVITE conveying an conference call, a user-to-user > gaming session, or what? We can't programmatically determine what an > INVITE with no SDP means. So if I'm following your argument here wrt > INFO, the analogous solution would be to deprecate INVITE unless it > always has SDP. > > But wait, there's more... Again, using your line of thought for INFO, > SDP may not be good enough: > > "However, as we learned in the messaging community [7], relying > upon the MIME type alone is not sufficient to determine the context of > the message. Clearly, as shown in the previous paragraph [which > describes using the MIME type of an INFO as a negotiation mechanism], > the message content relates to the message context. However, it is quite > easy to imagine situations where the same content type has multiple > meanings for a User Agent." > > So if the content relates to the message context, and the content and > type can be ambiguous, such as the INVITE contains SDP, or the SDP > contains an audio stream (is it a conference or is it a podcast or what) > or worse, SDP that contains content types that are not well-known, then > clearly SIP and SDP are not enough to correctly identify what the User > Agent is to do with this request. Hence, a mechanism such as > P-Preferred-Service rears it's ugly head. > > As a result, if I understand you correctly, rather than correct the > negotiation problem (more like just write it down because it's already > being neogitated out there in the wild in many cases) and let the UAs > deal with it, you'd rather deprecate the whole thing in favor of > something else. Correct? > > Also, your list of examples is missing one usecase that KPML definitely > does not address (but session timers does): INFO is used to detect if a > call is still alive. > > Cheers, > Brian > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ 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
