...and I guess you would also use another content-disposition value than "session" in your usage (again, since INFO cannot be used to directly modify the SIP session).
NOW I'm done with the reply to your e-mail ;) Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:[EMAIL PROTECTED] > Sent: 23. heinäkuuta 2007 3:37 > To: Adam Roach > Cc: IETF SIP > Subject: RE: [Sip] INFO and Content Negotiation > > > 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 > _______________________________________________ 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
