Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt

From: Lavis Zhou <[email-masked]>
Date: Thu, 08 Mar 2007 20:25:59 +0800

Hi,
Some doubts or comments about this draft:
1. Section 3, Line 237, for the statement 
"In either case, the Request-URI would be
   a SIPS URI."
It's better to mention Request-URI in which hop is a SIPS URI, so it may be
better to state as "In either case, the Request-URI between Proxy B and UA b
would be
   a SIPS URI."
2. Section 4, Line 348
"except for cases where the "last-hop exception"
   rule is in effect (in which case the Request-URI would be replaced by
   a SIP URI)."
This statement is conflicted with the statement referred by bullet 1 which
emphasises that Request-URI should be SIPS. Is it better to state that SIPS
cannot be downgraded to SIP even TLS will not be used in last-hop exception
to make it consistent?
3. Section 4.1, Line 430
" then the dialog is "tentatively" secure."
It's better to change the word "dialog" to "transaction or dialog" as there
may be a MESSAGE transaction which will not establish a dialog.
4. Section 5, Line 573
" If all the Contacts are SIPS, a SIPS AOR MUST also be used by the
   UAC.  If at least one of the Contacts is SIP or is neither SIP nor
   SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST also be used by
   the UAC."
And line 599
" A registrar MUST only accept a binding to a SIPS Contact if all the
   appropriate URIs are of the SIPS scheme: i.e., the Request-URI, the
   AOR (i.e., To header), the From header, the Contacts and all the Path
   headers."
>From the second part, it can be inferred that a SIPS contact can only be
registered by a SIPS AOR and SIPS contact and SIP contact cannot be
registered in one REGISTER message. But the first part is not mention this
meaning clearly. Is it better to append this implication?
5. Section 6 Line 	644,
" As mandated by [RFC3261]/8.1.1.8, in a request, if the Request-URI or
   top Route header field value contains a SIPS URI, the Contact header
   field MUST contain a SIPS URI as well."
Why top Route header filed value has to be checked? If the resource UAC want
to accessed which identified by Req-URI is a SIP URI, so it will be
non-secure, the secure link in one hop will help? And in this case, it will
mandatory one of the proxy in-between to RR as there is a conversion between
SIPS and SIP. Is any usage for this?
And the statement is conflict with the following statement (line 680)
" It is therefore
   RECOMMENDED that in this case, the Contact be a SIP URI"
So it's better to remove the top Route header check.
6. Section 6, Line 686
" When a target refresh occurs within a dialog (e.g., re-INVITE,
   UPDATE), unless there is a need to change it, the UAC SHOULD include
   a Contact header with a SIPS URI if the original request used a SIPS
   Request-URI."
As my understanding, the response of a target refresh request also can carry
a different Contact to update the target, so the statement may be should be
rewritten.
7. some Type errors
a. "The USC registers either a SIPS or a SIP AOR.", USC should be UAC
b. "Since upgrading from SIP to SIPS is allowed it other circumstances",
"it" should be "in".
c. "If the Request-UIR on the receiving", UIR should be URI.
d. "MAY or MAY NOTt use TLS", NOTt should be NOT.
e. nothwistanding should be notwithstanding.

Rgds,
Lavis

****************************************************************************
***********
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群
组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散
发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
****************************************************************************
**********
 
****************************************************************************
***********
This e-mail 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!
****************************************************************************
***********

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 6:00 AM
To: Jonathan Rosenberg
Cc: SIP
Subject: [Sip] draft-ietf-sip-sips Open Issues: Delivering requests
toregistered contact

I'm changing the Subject field because Jonathan is
pointing out another important issue.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, February 28, 2007 11:00
> To: Audet, Francois (SC100:3055)
> Cc: Robert Sparks; SIP
> Subject: Re: [Sip] draft-ietf-sip-sips Open Issues: GRUU
>
> Another related point, with current registrar behavior of 
> replacing the R-URI with the registered contact, if I send a 
> REGISTER request with a sips Contact and sips URI, and then 
> someone sends me a call to the sip version of my AOR, the 
> r-uri will be translated to the sips contact I had 
> registered. So how does a sips-only client reject this? I'm 
> referring to paragraph 4 in section 5. Not a GRUU question 
> per se, but related.

Actually, I the problem you are refering to affects not
only REGISTER, but any requests that has a Contact (like
an INVITE, if you expect mid-dialog requests).

That problem is something that I noticed was a big problem
in earlier versions of this draft (i.e., draft-ietf-sip-sips-00,
and the individual drafts draft-audet-sip-sips-guidelines).
Basically, it was broken

I had done a change in this version of the draft (i.e.,
draft-ietf-sip-sips-01) to address this. Look at the
second paragraph of section 4. (The call flows have been
adjusted for this too).

Basically, it says that the proxy must keep the same 
scheme (sip or sips) that was in the incoming request
before delivering it (i.e., sip -> sip, and sips -> sips).
If we don't do that, we'll have the problem you are
describing, but we'll also have a bigger problem with
mid-dialog requests.

To me this is consistent with the idea that schemes are 
equivalent from a routing perspective.

So yes, the proxy replaces the contact with the registered
contact, but it keeps the originial scheme of the request
that it is forwarding.

> I'll note that this issue is solved with UA loose route.

Yes it would. But I think proxies should nevertheless
keep the same scheme (sip or sips) when forwarding a
request to the client. Otherwise, it makes SIPS 
dependent on loose routes. I do not think that it would be
warranted to make that a dependency.

_______________________________________________
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

_______________________________________________
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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 9 Mar 2007 13:43:54 -0600

Thank you for your comments Lavis. I will incorporate most of them into version -03.
It will result on good clarfications.

On the following 2 items:

Item 2: 
    Yes, I guess one of the item that we will discuss in Prague (as per Appendix A),
    is the idea of deprecating the last hop exception. 

Item 5:
    I don't understand your question.
    And for the part about the conflict: there is no conflict. The case you are refering
    to in line 680 is the case where a request is sent over TLS using SIP Request-URI. It
    just recommends putting a SIP Contact instead of SIPS because of complications that 
    would arise.

> From: Lavis Zhou [mailto:[email-masked]] 
> Sent: Thursday, March 08, 2007 04:26
> Cc: 'SIP'
> Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt
> 
> Hi,
> 1. Section 3, Line 237, for the statement "In either case, 
> the Request-URI would be
>    a SIPS URI."
> It's better to mention Request-URI in which hop is a SIPS 
> URI, so it may be better to state as "In either case, the 
> Request-URI between Proxy B and UA b would be
>    a SIPS URI."
> 2. Section 4, Line 348
> This statement is conflicted with the statement referred by 
> bullet 1 which emphasises that Request-URI should be SIPS. Is 
> it better to state that SIPS cannot be downgraded to SIP even 
> TLS will not be used in last-hop exception to make it consistent?
> 3. Section 4.1, Line 430
> It's better to change the word "dialog" to "transaction or 
> dialog" as there may be a MESSAGE transaction which will not 
> establish a dialog.
> 4. Section 5, Line 573
> From the second part, it can be inferred that a SIPS contact 
> can only be registered by a SIPS AOR and SIPS contact and SIP 
> contact cannot be registered in one REGISTER message. But the 
> first part is not mention this meaning clearly. Is it better 
> to append this implication?
> 5. Section 6 Line 	644,
> Why top Route header filed value has to be checked? If the 
> resource UAC want to accessed which identified by Req-URI is 
> a SIP URI, so it will be non-secure, the secure link in one 
> hop will help? And in this case, it will mandatory one of the 
> proxy in-between to RR as there is a conversion between SIPS 
> and SIP. Is any usage for this?
> And the statement is conflict with the following statement 
> (line 680) " It is therefore
> As my understanding, the response of a target refresh request 
> also can carry a different Contact to update the target, so 
> the statement may be should be rewritten.
> 7. some Type errors
> a. "The USC registers either a SIPS or a SIP AOR.", USC 
> should be UAC b. "Since upgrading from SIP to SIPS is allowed 
> it other circumstances", "it" should be "in".
> This e-mail 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!
> Subject: [Sip] draft-ietf-sip-sips Open Issues: Delivering 
> requests toregistered contact
> 
> I'm changing the Subject field because Jonathan is pointing 
> out another important issue.
> 
> > Another related point, with current registrar behavior of replacing 
> > the R-URI with the registered contact, if I send a REGISTER request 
> > with a sips Contact and sips URI, and then someone sends me 
> a call to 
> > the sip version of my AOR, the r-uri will be translated to the sips 
> > contact I had registered. So how does a sips-only client 
> reject this? 
> > I'm referring to paragraph 4 in section 5. Not a GRUU 
> question per se, 
> > but related.
> 
> Actually, I the problem you are refering to affects not only 
> REGISTER, but any requests that has a Contact (like an 
> INVITE, if you expect mid-dialog requests).
> 
> That problem is something that I noticed was a big problem in 
> earlier versions of this draft (i.e., draft-ietf-sip-sips-00, 
> draft-ietf-sip-sips-01) to address this. Look at the second 
> paragraph of section 4. (The call flows have been adjusted 
> for this too).
> 
> Basically, it says that the proxy must keep the same scheme 
> (sip or sips) that was in the incoming request before 
> delivering it (i.e., sip -> sip, and sips -> sips).
> Yes it would. But I think proxies should nevertheless keep 
> the same scheme (sip or sips) when forwarding a request to 
> the client. Otherwise, it makes SIPS dependent on loose 
> routes. I do not think that it would be warranted to make 
> that a dependency.
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Lavis Chow <[email-masked]>
Date: Mon, 12 Mar 2007 14:31:22 +0800

Hi, 
Thanks for you reply, some more rough comments:

1. For Item 5 Line 680, It just mentioned that the Req-URI is SIP URI, but
if the Top route of that request is SIPS URI, then as per the rule of
[RFC3261]/8.1.1.8, Contact will be a SIPS URI. So if the intention is just
SIP with TLS, then it's better mention that top Route is not SIPS too.
And another concern for this item is what's the implication by checking the
top route besides the Req-URI.

2. This document had clarified the SIPS usage in Req-URI/Contact very
clearly. But I feel that the usage of SIPS in Route, RR, Path, Service-Route
is not clear. 
A. If the Req-URI of dialog establishing INVITE is SIP-URI, is it possible
that one Proxy insert a SIPS URI in RR? What's the implication for that?
Same for PATH, Service-Route of REGISTER message? Or this behavior is not
allowed?

B. If one UA register with SIPS contact, then Proxy will return a SIPS
version of Service-Route. Later if the UA want to contact a SIP URI
resource, what behavior is recommended: a. REGISTER with a SIP contact. b.
use these SIPS Routes and Contact, so it will mandates one proxy in-between
to record-route to conduct the SIP/SIPS conversion, How he know one of the
Proxy is willing to do it?

Rgds,
Lavis

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Saturday, March 10, 2007 3:44 AM
To: Lavis Zhou
Cc: SIP
Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-sips-02.txt

Thank you for your comments Lavis. I will incorporate most of them into
version -03. It will result on good clarfications.
On the following 2 items:
Item 2: 
    Yes, I guess one of the item that we will discuss in Prague (as per
Appendix A), is the idea of deprecating the last hop exception. 
Item 5:
    I don't understand your question.
    And for the part about the conflict: there is no conflict. The case you
are refering to in line 680 is the case where a request is sent over TLS
using SIP Request-URI. It just recommends putting a SIP Contact instead of
SIPS because of complications that would arise.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 12 Mar 2007 19:39:54 -0500

> 1. For Item 5 Line 680, It just mentioned that the Req-URI is 
> SIP URI, but if the Top route of that request is SIPS URI, 
> then as per the rule of [RFC3261]/8.1.1.8, Contact will be a 
> SIPS URI. So if the intention is just SIP with TLS, then it's 
> better mention that top Route is not SIPS too.
> And another concern for this item is what's the implication 
> by checking the top route besides the Req-URI.

OK. I get it now: I'll clarify.

> 2. This document had clarified the SIPS usage in 
> Req-URI/Contact very clearly. But I feel that the usage of 
> SIPS in Route, RR, Path, Service-Route is not clear. 
>
> A. If the Req-URI of dialog establishing INVITE is SIP-URI, 
> is it possible that one Proxy insert a SIPS URI in RR? What's 
> the implication for that?
> Same for PATH, Service-Route of REGISTER message? Or this 
> behavior is not allowed?

That is a good point. 

The first case, i.e., SIPS to SIP is the "last hop exception". 
Like it or not, it is there now, so that's why it is documented.
I will clarify that.

The second case, i.e., SIP to SIPS was initially there to cover
the "upgrade scenario" that was in previous versions of the
draft (i.e., when the client registers with SIPS), but a SIP
request is sent to it.

This new version of the draft doesn't work like this because it 
broke many things. I need to adjust some of the wording in
section 4 on this because it also confused EKR who had also a
comment on this.

The net-net of this is that I do not see any use case for
the SIP-to-SIPS conversion. In fact, it's probably a pretty
bad idea for a server to do something like this because the
receiver of the request will believe the request was sent
securily, while it was not. I'll try to put some wording to
that effect. I think EKR had a similar comment about "

> B. If one UA register with SIPS contact, then Proxy will 
> return a SIPS version of Service-Route. Later if the UA want 
> to contact a SIP URI resource, what behavior is recommended: 
> a. REGISTER with a SIP contact. b.
> use these SIPS Routes and Contact, so it will mandates one 
> proxy in-between to record-route to conduct the SIP/SIPS 
> conversion, How he know one of the Proxy is willing to do it?

I understand what you are saying now. I think it should work like this:

1 - If a UA registers with a SIPS contact, the registrar MUST 
    return a service route consisting of SIP URIs if the intent
    of the registrar is to allow both SIP and SIPS to be used 
    in requests sent by that client. 

2 - If a UA registers with a SIPS contact, the registrar MUST
    return a service route consisting of SIPS URIs if the intent
    or the registrar is to allow only SIPS URIs to be used in
    requests sent by that UA.

3 - It is the responsibility of the UAC to use a Route 
    header consisting of all SIPS URIs when using a SIPS 
    Request-URI and contact. If the service route was SIP,
    it is done by replacing the scheme of the entries with SIPS.

I can clarify this in the document if everybody is OK with this.