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

From: Qian Sun <[email-masked]>
Date: Tue, 19 Jun 2007 18:03:44 +0800

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.

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.

3. I guess it might be a typo in Figure 2 "8. 200K OK", maybe you meant "200 OK"?

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip