Hi, Robert and Gonzalo IMO, "multiple refer" doesn't need AIB part of Referred-By. As Gonzalo said, the relay (e.g. conference server) understand what is going on, it must have authenticated the identity of the Referrer. So the Referred-By header field and 'recipient-list-history'(the same function as Refer-To) are creditable for final REFER-Target.
The triggered SIP message sent by the relay just needs to include Referred-By header field (maybe plus recipient-list-history), the Referred-By token is not necessary (like the example "7.2. Insecure REFER" in rfc3892). The information in Referred-By header field is still very useful for final REFER-Target to learn the source of the message. It's not worth writing a separate spec for this, just adding few texts to this draft may be OK. Since this draft has mentioned Refer-Sub, why not says something about Referred-By? BTW, there are very few commercial IMS implementations on the planet, but we believe the future of IMS must not bad, maybe same to Referred-By with AIB. Cheers, Qian -----Original Message----- From: Robert Sparks [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 10:43 PM To: Gonzalo Camarillo Cc: Qian Sun; Miguel Garcia; sip; Aki Niemi; [EMAIL PROTECTED]> <[EMAIL PROTECTED] Subject: Re: [Sip] Re: [Sipping] RE: Comments on draft-ietf-sip-multiple-refer-01.txt As much as I like the Referred-By mechanism, before investing too much time into extending Referred-by for this case, ask yourself seriously if there is a customer for the work. AFAIK, there are no implementations of the AIB part of Referred-by on the planet (please speak up if you have one) and I know of no-one who plans to build it. Unless that changes, I think we'd all be better off spending our time working on things that people will actually use. RjS On Jul 17, 2007, at 1:34 AM, Gonzalo Camarillo wrote: > Hi, > > [moving this thread from the SIPPING list to this one (SIP) because > this is a SIP document now.] > > You are right. It is not trivial to use Referred-By with multiple > REFER. My suggestion is that, the same way as Referred-By is > specified as an extension of refer, you go ahead specify (if you > are interested) how to use Referred-by with multiple REFER in a > different spec. > > The body that the referrer would add to its REFER (which is what > the refer target would get) could be an XML list with the > recipients (those that can be disclosed) of the multiple REFER > (plus the referrer). Something similar to what recipients get after > a relay processes a list with copyControl attributes (draft-ietf- > sipping-capacity-attribute-04.txt)... in any case, since multiple > REFER is only used within a context of a service, you need to think > whether having a general Referred-By mechanism is needed or if such > functionality can be achieved in a different way within the > services multiple REFER is used in (e.g., conferencing). > > Cheers, > > Gonzalo > > > Qian Sun wrote: >> Hello, Gonzalo >> RFC3892 says: >> The sipfrag inside a Referred-By token MUST contain copies of the >> Refer-To, Referred-By, and Date header fields from the REFER >> request. >> In multiple refer case, the Refer-To header field includes content >> id, not the REFER-Target' URI. The content id is meaningless to >> the REFER-Targets, so the Referred-By token has to include the URI- >> List. >> Cheers, >> Qian >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:[EMAIL PROTECTED] >> Sent: Monday, July 16, 2007 4:23 PM >> To: Qian Sun >> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; >> [EMAIL PROTECTED]; [EMAIL PROTECTED]; >> [EMAIL PROTECTED] >> Subject: Re: Comments on draft-ietf-sip-multiple-refer-01.txt >> Hi, >> thanks for your comments. Answers inline: >> Qian Sun wrote: >> > Some comments on the draft... >> > >> > 1. I think it might be a good idea to talk something on >> "Referred-By" in this draft. Referred-By mechanism is still very >> useful for the multiple refer case. Maybe Refer-To related to a >> URI List with "bcc" or "anonymize" is a trouble. "Referred-BY” in >> the message header is to identify the initial REFER-Issuer. This >> information may be encrypted together with "refer-to" URI list, >> including the copy control level such as to/cc/bcc to the end >> user, i.e. REFER-Target, where the information will be decrypted >> by the REFER-Target. In this case the REFER-Recipient won’t be >> able to get rid of the "bcc" URI from the URI list, and the "bcc" >> URI will be sent to other REFER-Targets along with normal to/cc. >> This will be a problem to destroy the blind cc function. >> > However, the REFER-issuer may opt to not include a Referred-By >> token. For example: >> > REFER sip:[EMAIL PROTECTED];gruu;opaque=hha9s8d-999a SIP/ >> 2.0 >> > Refer-To: <cid:[email protected]> >> > Referred-By: Carol <sip:[EMAIL PROTECTED]> >> > Content-Type: application/resource-lists+xml >> > Content-Disposition: recipient-list >> > Content-Length: 362 >> > Content-ID: <[EMAIL PROTECTED]> >> > >> > <?xml version="1.0" encoding="UTF-8"?> >> > <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> >> > <list> >> > <entry uri="sip:[EMAIL PROTECTED]" /> >> > <entry uri="sip:[EMAIL PROTECTED]" /> >> > <entry uri="sip:[EMAIL PROTECTED]" /> >> > </list> >> > </resource-lists> >> > >> > When the URI list has no "bcc" or "anonymize" URI, REFER-issuer >> may include the Referred-By token in the REFER body. >> The way Referred-By works is not affected by what this draft says. >> Therefore, I do not see the need to talk about it. >> > >> > 2. Nested refer in multiple refer is very interesting, I >> believe it could be a good idea to enroll a "multiple nested >> refer" example into this draft. Just for an example: >> > REFER sip:[EMAIL PROTECTED];gruu;opaque=hha9s8d-999a >> SIP/2.0 >> > Refer-To: <cid:[email protected]> >> > Content-ID: <[EMAIL PROTECTED]> >> > >> > <?xml version="1.0" encoding="UTF-8"?> >> > <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> >> > <list> >> > <entry uri="sip:[EMAIL PROTECTED] >> 3Dsip:conf-123%40shenzhen.example.com" /> >> > <entry uri="sip:[EMAIL PROTECTED] >> 3Dsip:conf-123%40shenzhen.example.com" /> >> > </list> >> > </resource-lists> >> > In this case, the REFER-Recipient acts as a Refer List service, >> has the similar function to the MESSAGE List service, i.e. >> receives a REFER with URI-List and distributes some REFERs to each >> address in the URI-List. >> > Note that, there is only one final REFER-Target in above >> "nested multiple refer" example, not multiple REFER-Targets. In >> some situations, this convergent feature is useful. >> The draft says the following: >> Additionally, REFER-Recipients SHOULD only accept REFER requests >> within the context of an application the server understands >> (e.g., a >> conferencing application). >> this text was added to avoid relays being used as random traffic >> forwarders. Therefore, since a relay needs to understand what is >> going >> on (e.g., a multiple REFER to trigger BYEs towards several conference >> attendees) and currently there is no service that uses nested >> refers, I >> do not think we need to talk about it. >> > >> > 3. I guess it might be a typo in Figure 2 "8. 200K OK", maybe >> you meant "200 OK"? >> yes, thanks for pointing it out. We will fix it. >> Thanks, >> Gonzalo >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use [EMAIL PROTECTED] for questions on current sip >> Use [email protected] for new developments of core 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
