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.
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]:conf-123%40shenzhen.example.com" />
<entry uri="sip:[EMAIL PROTECTED]: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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
