Subject: [Sip] Comments on draft-ietf-sip-sips-02

From: EKR <[email-masked]>
Date: Sun, 11 Mar 2007 10:45:17 -0700

$Id: draft-ietf-sip-sips-02-rev.txt,v 1.1 2007/03/11 17:56:56 ekr Exp $

Overall this document appears to be in pretty good shape. Some
mostly editorial comments...

S 4.
   Although not mandated specifically in [RFC3261], the implication is
   that a resource described by a SIPS URI can not be "downgraded" to a
   SIP URI by just changing the scheme, unless it is the "last hop
   exception" described in Section 3.  This specification clarifies that
   a resource described by a SIPS URI MUST NOT be "downgraded" to a SIP
   URI by changing the scheme, or by sending the associated request over
   a non secure link, 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 document is targeted at Info, right? Isn't the 2119 language
kind of weird then?

   route it to Bob at Request-URI sips:[email-masked].  If a
   request is sent to AOR sip:bob@examplecom, Bob's proxy will route it
   to Bob at Request-URI sip:[email-masked] (because of the
   "upgrade" scenario described above, and the substitution of SIP to
   SIPS).

This should be sips:[email-masked], right?

    recommends that if the UAC decide to recurse to the SIP URI, it

I'm not sure I would use the word recurse here or below..

S 4.2.
Can you explain how each of thexe examples come about?

S 5.
   Furthermore, it is a matter of local policy for a UA to accept
   incoming requests addressed to a URI scheme that does not correspond
   to what it used for registration.  For example, a UA with a policy of
   "always SIPS" MUST address the Registrar using a SIPS Request-URI
   over TLS, MUST register with a SIPS Contact, and MUST reject requests
   addressed to a SIP Request-URI with 403 "Forbidden".  A UA with a
   policy of "best-effort SIPS" MUST address the Registrar using a SIPS
   Request-URI over TLS, MUST register with a SIPS Contact, and MUST
   accept requests addressed to either SIP or SIPS Request-URIs.  A UA
   with a policy of "No SIPS" MUST address the Registrar using a SIP
   Request-URI, MAY or MAY NOTt use TLS, MUST register with a SIP AOR
   and a SIP Contact, and MUST accept requests addressed to a SIP
   Request-URI.

I'm having some trouble with this normative language when you've
just said it's "local policy". Do these policies have any other
effect than to implement this language?

S 10.
Can we get a picture of the topology here?

I would break out the registration flow, which seems to be the same
for all these calls, and then not repeat it in each example.

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Sun, 11 Mar 2007 15:45:28 -0500

> This document is targeted at Info, right? Isn't the 2119 language

Arguable.

If the doc said "According to Section X of RFC 3261, the UA MUST NOT
do", then we wouldn't have a problem because we'd simply be quoting
RFC 3261, and certainly an informational document can quote a 
standards-track document.

The argument here is one step further removed. It's saying that, 
although RFC 3261 doesn't say this directly, it's what RFC 3261 implies. 
Therefore, by the strength of this implication (and the standards-track 
status of RFC 3261), we MUST NOT downgrade the SIPS URI.

This document doesn't declare this to be a rule -- it references RFC 
3261 as the declarer of and authority for the rule. It's just clarifying 
what RFC 3261 already means.

Now, if we were CHANGING what RFC 3261 means, we'd need a 
standards-track document that updates RFC 3261.

...

> effect than to implement this language?

here, the 2119 language is relative. It is predicated by a speculative 
-- "If the policy is X, then to support it, the UA MUST do Y". I believe 
this to be a legitimate modality for the language of RFC 2119.

That's rather different from saying "The policy MUST be X". This is an 
absolute rather than relative, and would require a standards-track document.

One thing that isn't clear here is that the policies in 5.5 are simply 
examples. If we were to be defining these policies in such a way that 
we'd expect other documents to normatively refer to them -- such as 
"Because the client implements the standard "best-effort SIPS" policy 
defined in RFC XXXXX, it MUST . . . " then we'd need  a much clearer 
definition of the policy, an IANA registry for those policies and 
probably a standards-track document to define the policies.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 12 Mar 2007 20:29:30 -0500

Thanks Eric. I'll incorporate your proposed changes in -03.

See below. 

> -----Original Message-----
> From: EKR [mailto:[email-masked]] 
> Sent: Sunday, March 11, 2007 10:45
> To: [email-masked]
> Subject: [Sip] Comments on draft-ietf-sip-sips-02
> 
> Overall this document appears to be in pretty good shape. 
> Some mostly editorial comments...
> 
> S 4.
> This document is targeted at Info, right? Isn't the 2119 
> language kind of weird then?

Yeah, I guess Dean also had a comment on this.

Personnally, I think the document has to say what it has to say. I
wouldn't 
water it down and make it less useful.

I have removed already the statements that ACTUALLY MODIFIED RFC 3261 
(like the "deprecate last-hop exception), and the "there is an error in
the
ABNF concerning the transport parameter" (although for the last one, it 
lists the error and says a further document will make that change. That 
allowed the draft to get rid of the "Obsoletes: RFC 3261" statement.
Good.

It also allowed us to say "Informative". The idea, as Dean points out,
is that
it doesn't really change the essence of RFC 3261, but merely clarifies
it.
My personal preference would be NOT to consider it to be "Informative", 
but, as Dean was saying, it's debatable. To me it doesn't change
3261, but it certainly defines requirements for supporting sips that are
not described properly in 3261.

Whether we call it "informative" or not, is something that we should
probably discuss with the Chairs.
 
> This should be sips:[email-masked], right?

Actually, no, but the previous part of the section is wrong...

In this version of the draft, as described in a previous thread, the
idea
is that the proxy keeps the same scheme as the orininal request when it
forwards the request to the UA. 

I now realise that I've updated other sections but not this one. I'll 
fix it in -03. 

> I'm not sure I would use the word recurse here or below..

Hum, I've used terminology from 3261 (p.98 for example). Any specific
reason
why not to use it? Any idea what to replace it with?

> Can you explain how each of thexe examples come about?

Yes, I will.

Basically, the first one is the "last hop exception". 

The second one has no use case. I'll specifically say that it is NOT 
RECOMMENDED.

> I'm having some trouble with this normative language when 
> you've just said it's "local policy". Do these policies have 
> any other effect than to implement this language?

Those should be viewed as examples of Policies. I should reword it to 
avoid 2119 terminology. Otherwise, I'm mandating the Policies which I
probably shouldn't do.

Good catch.

> I would break out the registration flow, which seems to be 
> the same for all these calls, and then not repeat it in each example.

Good point. I will do both in -03.