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

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 16 Jul 2007 11:22:32 +0300

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

---

From: Qian Sun <[email-masked]>
Date: Mon, 16 Jul 2007 16:48:37 +0800

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,

Gonzalo

---

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

Hi,

since this is now a SIP document, I am going to move this thread to the 
SIP mailing list.

Cheers,

Gonzalo

Qian Sun wrote:
> 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
> 
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
>  > 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.
>  > 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.
>