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

["James M. Polk" <[e-mail]>]

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


At 10:39 AM 11/10/2004 -0500, Janet P Gunn wrote:

>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.
>----------------------------------------------------------------------------------------


cheers,
James

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


_______________________________________________
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