Hello, Paul Your information is very useful. We are trying to achieve some application service features by using REFER method, the referred SIP request is needed to carry a specified message-body. But the hname "body" can only include very limited information, so we consider content-id mechanism. Now it seems a new disposition type may be better. To the security risk, I think this is an inherent question of REFER, RFC 3515 and REFERRED-BY have talked a lot about this.
I greatly appreciate your help! Cheers, Qian -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Friday, June 22, 2007 9:17 PM To: Qian Sun Cc: [EMAIL PROTECTED]; 'IETF SIP List' Subject: Re: [Sip] Comments on draft-camarillo-sip-body-handling-01 Qian Sun wrote: > Hello, > Thanks, Paul. So if a UA wants a SIP request triggered by > the REFER to include a specified body, we can not use the > hname "body". You can use "body" - but then the *value* of the body to be included is taken from the value of the "body" parameter. I just searched through my collection of sip drafts and RFCs (several years worth) for uses of this, and I only found three: draft-mahy-sip-peer-3pcc-00 (2002 - expired) draft-johnston-sipping-cc-uui-01 (2007 - active) draft-ietf-sipping-transc-conf-03 (2006 - in RFC Ed Queue) Of these, draft-ietf-sipping-transc-conf-03 doesn't show an actual encoded body - it just proposes use without showing it. But at least it appears a plausible use. The usage shown in the other two is, IMO, questionable. I think it remains to be seen if this construct will actually be supported. The use of header parameters of this sort, by the receiving UA is discretionary. It must be, because there are security risks to doing whatever someone asks you to do. So I don't think you can in general be confident that your request will be honored if you use this mechanism. > Can we define a new disposition type to explicitly > indicate the triggered SIP request by REFER should carry the > corresponding content body? > > For example: > REFER sip:[EMAIL PROTECTED] SIP/2.0 > Refer-To: <sip:[EMAIL PROTECTED]; method=MESSAGE> > Content-Type: text/plain > Content-Disposition: referred-body > Hello World! I suppose you could propose such a change. I don't know if it would be accepted. > Then the MESSAGE triggered by the REFER will include the > content which disposition type is "referred-body", i.e., > "Hello World!" What are you trying to achieve by all of this? Paul > Cheers, > Qian > > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 21, 2007 8:52 PM > To: Qian Sun > Cc: [EMAIL PROTECTED]; 'IETF SIP List' > Subject: Re: [Sip] Comments on draft-camarillo-sip-body-handling-01 > > Qian Sun wrote: >> Hello, >> >> In section 4.3, there is the following text: >> "(e.g., a Refer-To header field with a Content-ID URL pointing to a body >> part whose disposition type is 'session'), the UAS SHOULD return a 415 >> (Unsupported Media Type) response." >> >> Can I include a Content-ID URL like this? >> Refer-To: <sip:[EMAIL PROTECTED]"CID:[email protected]"> >> And the Content-ID URL point to a body part, whose disposition type is not ' >> recipient-list', might be 'session'. > > The construction seems to be nonsense. When the REFER containing this is > acted upon it would result in an INVITE with a body containing the CID URI. > > I assume you want the resulting INVITE to have the referenced body part > as its body. That sounds possibly useful, but I don't see any way to > disambiguate the cases. > > The use of "body" as a SIP URI parameter is interesting for completeness > with header parameters, but I have never seen a use of it. The use of > header parameters in general is pretty limited. > >> Maybe this draft could write something about the special hname "body", since >> the purpose of the draft is to clarify how message bodies are handled in SIP. > > It seems off-topic to what the draft is otherwise tackling. > > Paul > >> Cheers, >> Qian >> >> >> >> >> >> _______________________________________________ >> 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
