Subject: Re: [sipcore] rfc4244bis

From: fanyanping <[email-masked]>
Date: Thu, 16 Jul 2009 09:48:16 +0800

Hi mary,

my response are inline below [nancy] , thanks:)

> -----Original Message-----
> From: Mary Barnes [mailto:[email-masked]] 
> Sent: Wednesday, July 15, 2009 10:46 PM
> To: fanyanping
> Subject: RE: [sipcore] rfc4244bis
> 
> Hi Nancy,
> 
> My responses are inline below [MB].  Note, it does not look 
> like your original message went to the mailing list. Feel 
> free to respond to the mailing list. 
> 
> Regards,
> Mary. 
> 
> -----Original Message-----
> From: fanyanping [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2009 5:24 AM
> To: [email-masked]
> Cc: Barnes, Mary (RICH2:AR00)
> Subject: Re: [sipcore] rfc4244bis
> 
> 
> Hi mary,
> 
> I have read the draft of draft-barnes-sipcore-rfc4244bis-02.txt, there
> are some issues i don't understand clearly, as blow: 
> 1, section 4.1 mentions
> UAC that wants to ensure that privacy not be applied to its identity
> MUST include a Privacy header with a priv- value of "none."
> 
> but section 6.3.1(Privacy in the History-Info Header) doesn't  has
> relevant description, can a proxy include a Privacy header 
> with a priv-
> value of "none" to a specifical hi-entry??  how  to handle 
> the "none" in
> different cases?
> 
> [MB] We have not precluded the use of "none". We did have a 
> long debate
> that the "none" in the hi-entry cannot override a privacy 
> header at the
> request level.  And, section 4.1 is discussing privacy at the request
> level. So, I'm not sure what additional functionality you might get if
> you added "none" to a specific hi-entry - in a sense that's 
> the default
> IF there is no privacy header at the request level.[/MB]

[nancy] I get it , thanks, review RFC3323, i find i make a mistake,:)

> 
> 2,section 6.1 mentions
> The hi-target is added for a hi-entry when it is first added in a
> History-Info header field
> 
> but in the previous draft, the hi-target is not added for a hi-entry
> when it is first added in a History-Info header field,  it is added to
> the last hi-entry received in the request 
> 
> compare the two methods, what is the advantage of the first one? i see
> that rosenberg's target-uri-delivery draft adopts the second one
> 
> [MB] You are correct - we have changed the solution approach. 
> The reason
> we've done so is that we want to capture the mechanism by 
> which the new
> target was determined.  At that point in time, as well, we 
> can determine
> whether the previous target (i.e., the one in the incoming 
> Request) was
> an "aor". So, we now tag the previous entry with the "aor" tag if
> appropriate. The first method does add some complexity for the 3xx
> handling, which is why you see a lot more text for that in the new
> version. The second approach was trying to be consistent with how the
> entries are tagged with the "Reason" header. But, we decided that by
> tagging the new hi-entry we are actually capturing more (accurate)
> information.  We have tried to be precise in the text, so if you can
> point out any text that makes this unclear, that would be 
> very helpful.
> [/MB]
 
[nancy] previously, the reason header and hi-target parameter in the
hi-entry are matched, but now i need to find the next hi-entry's hi-target
parameter when see a reason header,it makes me a a bit confused. :)

> 
> ps:
> can somebody give me an answer about the following questions? 
>   I don't
> find
> the  exact description in RFC 3261, thanks in advance!!!   
> 
> 1, how does the proxy handle the request which the 
> request-URI includes
> a maddr parameter in different cases?
> [MB] This is described in section 16.5 of RFC 3261:
>    "If the Request-URI of the request contains an maddr parameter, the
>    Request-URI MUST be placed into the target set as the only target
>    URI, and the proxy MUST proceed to Section 16.6."
> 
> So, the only thing the proxy can do is to use the maddr parameter -
> i.e., it's the new target.  This hi-entry would be tagged as 
> "rt". And,
> in this case the previous entry is NOT tagged as an "aor".[/MB]

[nancy] you mean the request-URI should be replaced with the address in the
maddr parameter?? or  delete the maddr in the reqest-URI and add it to the
route header??

> 
> 
> 2, If  the domain of request-URI indicates is not that the proxy be
> responsible for,what actions should the proxy be taken?
> [MB] Again per section 16.5:
>    "If the domain of the Request-URI indicates a domain this 
> element is
>    not responsible for, the Request-URI MUST be placed into the target
>    set as the only target, and the element MUST proceed to the task of
>    Request Forwarding (Section 16.6)."
> 
> So, the only thing the proxy can do is to forward the request to the
> next hop proxy.  This entry would be tagged as "rt".  And, in 
> this case
> the previous entry is NOT tagged as an "aor". [/MB]

[nancy] you mean don't change the request-URI ,and add the address of next
hop proxy to the route header,right?  

> 
> IMHO, the two cases are not retarget
> [MB]  In the document the term "retarget" is used in the most general
> sense (as it was in RFC 4244) to cover all of these cases - i.e.,
> forwardings (ala "rt") as well as the other cases - basically
> encompassing the process described in section 16.5 of RFC 3261. The
> primary purpose that term really serves is to make the 
> document far less
> wordy and easier to read.[/MB]
> 

 [nancy] I see the definition of 'retarget' in your draft as below:

   The term "retarget" is used in this document to refer both to the
   process of a Proxy Server/User Agent Client (UAC) changing a Uniform
   Resource Identifier (URI) in a request based on the rules for
   determining request targets as described in Section 16.5 of [RFC3261]
   and the subsequent forwarding of that request as described in section
   16.6 of [RFC3261].

what 's the mean of "subsequent forwarding"??  i see that it needs to change
the reqeust-URI first, right?? in this way, the  ordinary forwarding can not
be included in "retarget",such as the second question i describe as before.

> 
> Best Regards.
> 
>  
> nancy
> 
> *******************************************************************
> This email and its attachments contain confidential information from
> HUAWEI, which is intended only for the person or entity whose 
> address is
> listed above.
> Any use of the information contained herein in any way (including, but
> not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons
> other than the intended recipient(s) is prohibited. If you 
> receive this
> e-mail in error, please notify the sender by phone or email 
> immediately
> and delete it!
> *******************************************************************
>

---

From: "Ian Elz" <[email-masked]>
Date: Thu, 16 Jul 2009 15:53:32 +0200

Nancy, Mary,

We have discussed this issue previously.

The key issues are outside the scope of the 4244bis draft and needs to
be discussed separately.

The issue with RFC3323 is that this RFC only discusses privacy from an
originating and terminating user perspective. Separate discussions are
required on how privacy for 3rd party identities included in a sip
messages is handled.

The current interpretation that you cannot override what is included in
the Privacy header results in two specific issues:

- originating user includes a Privacy value of user/header/id which
means that the 3rd party identity has the same privacy. If the 3rd party
identity should be allowed then this may impact services which use the
third party identity. The example which has been quoted is the Freephone
call where the Freephone number is used for call handling. This is
inconvenient for services which need to use this information.

- originating user explicitly specifies "Privacy: none" in the
originating request. This means that the 3rd party identity cannot be
protected. This has much more serious impact as it makes SIP as defined
'not fit for purpose' in most regulated telephony environments. This is
due to regulatory requirements to allow the privacy for each user to be
specified and handled correctly.

This however is outside the scope of the H-I changes but I would suggest
that the new draft specifically allows the inclusion of the 'none' value
in the escaped Privacy header in the hi-targeted-to-uri.

Ian

-----Original Message-----
From: fanyanping [mailto:[email-masked]] 
Sent: 16 July 2009 02:48
To: 'Mary Barnes'
Cc: [email-masked]
Subject: Re: [sipcore] rfc4244bis

 Hi mary,

> My responses are inline below [MB].  Note, it does not look like your 
> original message went to the mailing list. Feel free to respond to the

> mailing list.

> relevant description, can a proxy include a Privacy header with a 
> priv- value of "none" to a specifical hi-entry??  how  to handle the 
> "none" in different cases?
> 
> [MB] We have not precluded the use of "none". We did have a long 
> debate that the "none" in the hi-entry cannot override a privacy 
> header at the request level.  And, section 4.1 is discussing privacy 
> at the request level. So, I'm not sure what additional functionality 
> you might get if you added "none" to a specific hi-entry - in a sense 
> that's the default IF there is no privacy header at the request 
> level.[/MB]

> we've done so is that we want to capture the mechanism by which the 
> new target was determined.  At that point in time, as well, we can 
> determine whether the previous target (i.e., the one in the incoming
> Request) was
> point out any text that makes this unclear, that would be very 
> helpful.
> [/MB]
 
[nancy] previously, the reason header and hi-target parameter in the
hi-entry are matched, but now i need to find the next hi-entry's
hi-target parameter when see a reason header,it makes me a a bit
confused. :)

> 1, how does the proxy handle the request which the request-URI 
> includes a maddr parameter in different cases?
> i.e., it's the new target.  This hi-entry would be tagged as "rt". 
> And, in this case the previous entry is NOT tagged as an "aor".[/MB]

[nancy] you mean the request-URI should be replaced with the address in
the maddr parameter?? or  delete the maddr in the reqest-URI and add it
to the route header??

>    "If the domain of the Request-URI indicates a domain this element 
> is
> next hop proxy.  This entry would be tagged as "rt".  And, in this 
> case the previous entry is NOT tagged as an "aor". [/MB]

[nancy] you mean don't change the request-URI ,and add the address of
next hop proxy to the route header,right?  

> primary purpose that term really serves is to make the document far 
> less wordy and easier to read.[/MB]
> 

what 's the mean of "subsequent forwarding"??  i see that it needs to
change the reqeust-URI first, right?? in this way, the  ordinary
forwarding can not be included in "retarget",such as the second question
i describe as before.

> HUAWEI, which is intended only for the person or entity whose address 
> is listed above.

> other than the intended recipient(s) is prohibited. If you receive 
> this e-mail in error, please notify the sender by phone or email 
> immediately and delete it!

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 16 Jul 2009 11:08:53 -0500

Ian,

Thanks for the response.

Just one question below [MB].

Mary.

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Thursday, July 16, 2009 8:54 AM
To: fanyanping; Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: RE: [sipcore] rfc4244bis

Nancy, Mary,

This however is outside the scope of the H-I changes but I would suggest
that the new draft specifically allows the inclusion of the 'none' value
in the escaped Privacy header in the hi-targeted-to-uri.
[MB] Are you suggesting that we allow this "none" even in the case where
there is for example, a privacy header "history" at the request level?
I'm not so comfortable with that as it overrides what the UAC might have
included in the original request.  If that's not what your suggesting,
what would adding "none" to an entry give you anyways?  An entity cannot
arbitrarily add "none" to entries added by another entity nor can it
override policy. [/MB]

Ian

-----Original Message-----
From: fanyanping [mailto:[email-masked]]
Sent: 16 July 2009 02:48
To: 'Mary Barnes'
Cc: [email-masked]
Subject: Re: [sipcore] rfc4244bis

 Hi mary,

---

From: "Ian Elz" <[email-masked]>
Date: Thu, 16 Jul 2009 18:18:54 +0200

Mary,

The problem that we have is that the 3rd party cannot explicitly specify
the privacy setting for his uri contained in the H-I entry.

Under the present interpretation inserting a value of 'none' in the H-I
entry would not have any effect.

In future discussions about 3rd party privacy the current interpretation
may be changed to a point where a value of 'none' in the H-I entry may
be able to explicitly identify the Privacy of the 3rd party header in
the H-I irrespective of what is included in the Privacy header.

I will admit that if 4244bis specifically states that 'none' may be
included in the H-I entry this may lead to confusion.

As long as the possibility to include the value 'none' in the escapes
header parameter of the hi-targeted-to-uri is not excluded then it may
be better to deal with this case when discussions relating to 3rd party
privacy are held.

Do you think that a separate discussion on third party privacy is
something that should be undertaken in sipcore and what is the best way
to start this discussion, a draft or just a discussion paper?

Regards

Ian

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: 16 July 2009 17:09
To: Ian Elz; fanyanping
Cc: [email-masked]
Subject: Privacy "none" (was RE: [sipcore] rfc4244bis

Ian,

Thanks for the response.

Mary.

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Thursday, July 16, 2009 8:54 AM
To: fanyanping; Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: RE: [sipcore] rfc4244bis

Nancy, Mary,

Ian

-----Original Message-----
From: fanyanping [mailto:[email-masked]]
Sent: 16 July 2009 02:48
To: 'Mary Barnes'
Cc: [email-masked]
Subject: Re: [sipcore] rfc4244bis

 Hi mary,

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 16 Jul 2009 11:35:38 -0500

Hi Nancy,

I'll skip the first point, since Ian responded to that and I to that
response. Additional comments below [MB2], noting that all the sections
I reference below are from RFC 3261.  I will note that you really can't
read 4244bis in isolation - it's described carefully within the context
of section 16.5 (Determining Request Targets) and section 16.6 (Request
forwarding). 

Mary. 

-----Original Message-----
From: fanyanping [mailto:[email-masked]] 
Sent: Wednesday, July 15, 2009 8:48 PM
To: Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: RE: [sipcore] rfc4244bis

 Hi mary,

 

[MB2] No. You would use the hi-target parameter associated with the
entry that has the reason header (in the current version).  The
hi-target parameter tells you the mechanism by which that
hi-targeted-to-uri was determined - we have to capture it when we
capture the request-URI or we lose that information.  The Reason still
tells you why that hi-targeted-to-uri was later retargeted. So, when you
first add the hi-entry, the only optional field you would have with
4244bis is the hi-target. When the Request-uri as reflected by the
hi-targeted-to-uri is "retargeted", then the Reason and "aor" parameters
may be added (if appropriate conditions are met).  In general, the
UAS/application wouldn't usually care about the last hi-entry, which
would only have the hi-target (if the last entity supports 4244bis).
But, we don't know that this is the last entry when we add the hi-target
parameter. 
[/MB2]

[nancy] you mean the request-URI should be replaced with the address in
the maddr parameter?? or  delete the maddr in the reqest-URI and add it
to the route header??
[MB2] In section 16.5 the proxy is building the target list. The use of
the target list to build the outgoing request is described in section
16.6. So, with the maddr, that is the only parameter in the target list,
thus when the outgoing request is built the maddr parameter will be the
Request-URI in the outgoing request. The processing for the route header
is described separately in section 16.4.    [/MB2]

[nancy] you mean don't change the request-URI ,and add the address of
next hop proxy to the route header,right?  
[MB2] Correct. Per my note above the processing for the route header is
described in section 16.4.   and it's added to the request in step 4 of
section 16.6 That's entirely independent of the determination of the
target list in section 16.5 and is transparent to the processing for the
History-Info header. [/MB2]

what 's the mean of "subsequent forwarding"??  i see that it needs to
change the reqeust-URI first, right?? in this way, the  ordinary
forwarding can not be included in "retarget",such as the second question
i describe as before.
[MB2] the term "subsequent forwarding" is specifically referencing the
processing in section 16.6 (Request Forwarding). The request URI for the
outgoing request is determined as described in section 16.6 using the
target list built in section 16.5 [/MB2]

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 16 Jul 2009 12:21:00 -0500

Hi Ian,

I think a paper/draft on this issue would be very useful for fleshing
out this problem.  It is somewhat beyond the strict charter of SIPCORE
at this point, so I'd defer to the chairs as to whether we should take
the discussion directly to SIPCORE or DISPATCH. The latter of course is
fine with me and may well help us to first determine the scope of the
potential work.

Thanks,
Mary.

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Thursday, July 16, 2009 11:19 AM
To: Barnes, Mary (RICH2:AR00); fanyanping
Cc: [email-masked]
Subject: RE: Privacy "none" (was RE: [sipcore] rfc4244bis

Mary,

Regards

Ian

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 16 July 2009 17:09
To: Ian Elz; fanyanping
Cc: [email-masked]
Subject: Privacy "none" (was RE: [sipcore] rfc4244bis

Ian,

Thanks for the response.

Mary.

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Thursday, July 16, 2009 8:54 AM
To: fanyanping; Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: RE: [sipcore] rfc4244bis

Nancy, Mary,

Ian

-----Original Message-----
From: fanyanping [mailto:[email-masked]]
Sent: 16 July 2009 02:48
To: 'Mary Barnes'
Cc: [email-masked]
Subject: Re: [sipcore] rfc4244bis

 Hi mary,