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 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]: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.
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
_______________________________________________
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
