Subject: [Sip] More general question on S-S-L mode in RPH

From: Janet P Gunn <[email-masked]>
Date: Wed, 10 Nov 2004 10:39:28 -0500

What do the S-S-L modes apply to?

In this case, I am just looking just at the dimension of which messages are
accepted, and which are rejected- ignoring the other features which have
been associated with the mode.

4.3.2 says that "mode" is a characteristic of the SIP element:

"When handling requests with unknown namespaces or priority values,
   elements can operate in one of three modes, "strict", "semi-strict"
   and "loose"."

This makes some sense to me (comments below).

There are other places that imply that the mode is a characteristic of the
domain.  4.3.3 says:

"Strict Mode is for administrative domains (or realms) that ..."

But table 1 in section 7 says:

"                                            New   New Error
Namespace  Levels   Mode    Operation   Rej. code  code    Reference
---------  ------   ----    ---------   ---------  ----    ---------
   dsn       5     strict   preemption      no      417    [This RFC]

   drsn      6     strict   preemption      no      417    [This RFC]

   q735      5     strict   preemption      no      417    [This RFC]

   ets       5  semi-strict preferential    no      417    [This RFC]

   wps       5  semi-strict preferential    no      417    [This RFC]

                   Table 1. Namespace Parameters"

Which makes "mode" a characteristic of the namespace.

This makes less sense to me.  If any of these namespaces appear in an RPH
in a SIP message which is being processed by a SIP element operating in
loose mode, they will NOT get the strict or semi-strict behavior specified
in Table 1.

It seems to me that the mode is/should be a function of the (SIP element,
namespace) pair.

For instance a SIP element could be "strict" for namespace A and
"semi-strict" for namespace B.

So a message with just A would succeed
A message with just B would be rejected
A message with A and B would succeed
A message with just C would  be rejected
A message with A and C would be rejected

Or the SIP element could be "strict" for namespace A, and "loose" for
everything else.

So a message with just A would succeed
A message with just B would be rejected
A message with A and B would succeed
A message with just C would  be rejected
A message with A and C would be succeed.

I don't think you could combine "semi-strict" and "loose" in the same SIP
element.

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 10 Nov 2004 10:43:00 -0600

Clearly this document needs to address the behaviors you want in a mode (if 
they remain in the document), and clearly semi-strict as defined is not 
exactly as you want it.

Are you missing something...?

Domains will operate their network as they see fit, and this document will 
not dictate how that is accomplished. This is a document that describes a 
header with several field values. Some field values can be used to prevent 
communications in known networks, so the expected behaviors of those field 
values should be articulated somewhere in a document where the header is 
defined (the IETF).

A concern is 2 years from now someone operating a network will want to use 
this header in their network and want guidance as to which field values to 
use from a list of predefined values, or suggest a new one be created for 
unique conditions.

Since SIP is an end-to-end protocol (not accounting for B2BUAs), a SIP 
message with this header may have one behavior in one network and a 
completely different (and potentially undesirable) behavior in another 
network.

The modes articulated in this document are to explain usages that "can" 
(not must) be experienced in some networks when using specific namespaces 
created for specific purposes. Each are as much to caution as they are to 
define the behavior of usage.

If a namespace has a general characteristic of preemption as a behavior in 
a known network(s) - that namespace should not be used by endpoints in 
another network that does not include the behavior of preemption. 
Undesirable consequences will occur when communicated between those networks.

This is all guidance, it's not a law anywhere

>Namespace  Levels   Mode    Operation   Rej. code  code    Reference

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: [email-masked]
Date: Wed, 10 Nov 2004 13:36:00 EST

> "semi-strict" for namespace B.

This doesn't make sense. Part of the use of the mode still is to determine 
what to do when the receiving element does not understand the namespace, that 
is, it thinks it needs a namespace but doesn't see one it understands. (This was 
the only use of the mode in version -04.) Becasue of this, the mode must be a 
function of the domain, or rather, of every element in the domain. It is not 
associated with a namespace. Each element must know what mode it is supposed 
to operate in independent of what namespace is being used.

Version -04 was based on an element or UAS operating in a specific mode and 
did not try to associate the mode with the namespace. This technical change is 
another reason why I believe that version -05 should be rejected.

Mike