Subject: [Sip] Re: [Sipping] RE: Comments on draft-ietf-sip-multiple-refer-01.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 17 Jul 2007 09:34:15 +0300

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-masked]]
> Sent: Monday, July 16, 2007 4:23 PM
> To: Qian Sun
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> 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-masked];gruu;opaque=hha9s8d-999a  SIP/2.0
>  >    Refer-To: <cid:[email-masked]>
>  >    Referred-By: Carol <sip:[email-masked]>
>  >    Content-Type: application/resource-lists+xml
>  >    Content-Disposition: recipient-list
>  >    Content-Length: 362
>  >    Content-ID: <[email-masked]>
>  >
>  >    <?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-masked]?method=BYE" />
>  >        <entry uri="sip:[email-masked]?method=BYE" />
>  >        <entry uri="sip:[email-masked]?method=BYE" />
>  >      </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-masked];gruu;opaque=hha9s8d-999a  SIP/2.0
>  >    Refer-To: <cid:[email-masked]>
>  >    Content-ID: <[email-masked]>
>  >
>  >    <?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-masked]?method=REFER%3FRefer-To%3Dsip:conf-123%40shenzhen.example.com" 
> />
>  >        <entry 
> uri="sip:[email-masked]?method=REFER%3FRefer-To%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-masked] for questions on current sip
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Robert Sparks <[email-masked]>
Date: Tue, 17 Jul 2007 09:43:10 -0500

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  
>> 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
>>  > 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.  
>>  > However, the REFER-issuer may opt to not include a Referred-By  
>> token. For example:
>>  > When the URI list has no "bcc" or "anonymize" URI, REFER-issuer  
>> may include the Referred-By token in the REFER body.
>>  > 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:
>>  >        <entry uri="sip:[email-masked]?method=REFER%3FRefer-To% 
>> 3Dsip:conf-123%40shenzhen.example.com" />
>>  >        <entry uri="sip:[email-masked]?method=REFER%3FRefer-To% 
>> 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.
>>  > 3. I guess it might be a typo in Figure 2 "8. 200K OK", maybe  
>> you meant "200 OK"?

---

From: Qian Sun <[email-masked]>
Date: Thu, 19 Jul 2007 09:47:53 +0800

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-masked]] 
Sent: Tuesday, July 17, 2007 10:43 PM
To: Gonzalo Camarillo
Cc: Qian Sun; Miguel Garcia; sip; Aki Niemi; [email-masked]> <[email-masked]
Subject: Re: [Sip] Re: [Sipping] RE: Comments on draft-ietf-sip-multiple-refer-01.txt

RjS

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Jul 2007 09:46:11 +0300

Hi,

as I stated before, at this point, if you think specifying this feature 
is useful, it should be done in a separate (new) spec. It is too late in 
the process to add new features to the multiple-refer draft.

Cheers,

Gonzalo