Hi, I forgot the part about the indication of the support.
I agree that Accept: application/sdp itself may not be enough to indicate the support for the specific usage. So, either you could have e.g. an option-tag, some application identifier, an extention to the Accept header - or we would simply say that INFO cannot be used to transport SDP (as I've said many times, I am not proposing to allow to use INFO for whatever people want to). Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: 23. heinäkuuta 2007 3:27 > To: Adam Roach > Cc: IETF SIP > Subject: RE: [Sip] INFO and Content Negotiation > > > Hi, > > I think it is clearly said that INFO is not to be used to > directly modify the SIP session, so unless there is an > application on top of the SIP session that understands this > information it would simply be rejected. > > Regards, > > Christer > > > > > > -----Original Message----- > > From: Adam Roach [mailto:[EMAIL PROTECTED] > > Sent: 22. heinäkuuta 2007 17:19 > > To: Christer Holmberg (JO/LMF) > > Cc: Eric Burger; IETF SIP > > Subject: Re: [Sip] INFO and Content Negotiation > > > > To rephrase what Eric is saying here in base principles: > > _inferring_ what can be done with INFO by examining > supported content > > types is a "Do What I Mean" mechanism (as opposed to a "Do > What I Say" > > mechanism). "Do What I Mean" is a well-known recipe for > > interoperability failure. (For a well constructed > discussion of this, > > see Jonathan's service indication draft). > > > > This is, for example, why we have an "Event" header field > in RFC 3265 > > instead of simply inferring the event package from MIME type. (In > > fact, this is why I started the draft that became 3265 in the first > > place -- with the dual uses of PINT and presence > threatening to take > > the SUBSCRIBE method down the path that INFO unfortunately ended up > > taking, an intervention was necessary). > > > > To re-cast Eric's example from a slightly different angle: > > imagine that a desired usage of INFO most naturally used > > application/sdp as its payload. How would one indicate support for > > such a usage? > > > > /a > > > > Christer Holmberg (JO/LMF) wrote: > > > Hi, > > > > > > I still don't get it, but let's take it face-to-face at > > some point :) > > > > > > Regards, > > > > > > Christer > > > > > > > > >> -----Original Message----- > > >> From: Eric Burger [mailto:[EMAIL PROTECTED] > > >> Sent: 22. heinäkuuta 2007 10:14 > > >> To: Christer Holmberg (JO/LMF); IETF SIP > > >> Subject: Re: [Sip] INFO and Content Negotiation > > >> > > >> That is the point - people have been saying, "I can > > negotiate INFO by > > >> using Content-Type." This is a tiny example where using > > Content-Type > > >> to negotiate "INFO Packages" falls apart. > > >> > > >> > > >> On 7/22/07 3:10 AM, "Christer Holmberg (JO/LMF)" > > >> <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >>> Why would I be expecting KPML, if I have only indicated > > >>> > > >> that I support > > >> > > >>> DTMF-over-INFO? > > >>> > > >>> If I was to expect KPML, I would first need to establish a > > >>> subscription for KPML (or, in our "controlled network", the > > >>> subscription would be established by default, and I would > > >>> > > >> know you are going to send KPML). > > >> > > >>> Regards, > > >>> > > >>> Christer > > >>> > > >>> > > > > > > > _______________________________________________ > 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 > _______________________________________________ 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
