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
