RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps

[Janet P Gunn <[e-mail]>]

James said:
---


> > 4 SIP messages that include the RPH with the ets or wps namespaces
should
> > include the authorization header (or equivalent mechanism)
(semi-strict)

this should be self evident in public networks....
---

Agree- my point was that this is part of "semi-strict" that IS desirable,
even if we want the treatment to be "loose" in terms of  treatment of an
unrecognized namespace.

Consider this  policy for a specific namespace
 - If the SIP element doesn't recognize the namespace , it ignores the
header (doesn't give any special treatment here, but passes it on if
appropriate- e.g., to a signalling gateway)
-  If the SIP element recognizes the namespace, but there is an invalid
value, the request (and the call) are rejected
-  If the SIP element recognizes the namespace, and the value, but the
authentication header doesn't pass muster, the request (and the call) are
rejected
-  If the SIP element recognizes the namespace, and the value, AND
authentication header is "good", then the request (and the call) get
special treatment here, and the RPH is passed on if appropriate- e.g., to a
signalling gateway.

Is this policy permitted by the current draft?  My reading is that this
policy is not permitted.

Section 4.3.2 says:
"When handling requests with unknown namespaces or priority values,
   elements can operate in one of three modes, "strict", "semi-strict"
   and "loose"."
and
       "If the request includes a 'Require' header field with the
   'Resource-Priority' option tag, a UAS MUST follow the strict or
   semi-strict mode rules, otherwise UAS and proxies MUST operate in
   loose mode."

Since the policy described above does not fit "strict", "semi-strict" or
"loose", it would seem to be forbidden.

Am I missing something?

Janet
----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip