Subject: RE: [Sip] re: WGLC: resource priority (3)

From: Janet P Gunn <[email-masked]>
Date: Fri, 16 Jan 2004 10:10:18 -0500

Just a very small quibble.

You say
"The trigger for our SIP R-P client is a particular phone number sequence.
Absence of that sequence means that all other calls from that client are
regular SIP messages."

That is one trigger, but there are other triggers for the NS/EP code point.
But that doesn't change your point that if the call doesn't "trigger" the
NS/EP code point, the RPH won't be there.

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

                      "Ken Carlberg"                                                                                            
                      <carlberg                To:      <[email-masked]>, <[email-masked]>                                   
                      @g11.org.uk>             cc:      <[email-masked]>                                                          
                                               Subject: RE: [Sip] re: WGLC: resource priority (3)                               
                      01/16/2004 08:19                                                                                          
                      AM                                                                                                        

> [MAP] You're going to have to explain how that could work, considering

> that the draft states:
>
> Every namespace must have a default level.
> The default is assumed in the absence of a priority level (in a
> message).
>
> That means that, if there is only one priority value in the
> namespace (such as "on") registered with IANA, it must be the
> default, and any INVITE that does not contain an RP-header is
> treated as if it contained the default value ("on").

You've just explained your own request.

> How would it be possible to signal the "off" value?

"off" = absence of message/signal, ie, the SIP Invite msg is the same as
if the R-P header didn't exist.  If I'm forced to have an "off" R-P
header value, than I'll need to write more code to recognize this, and
I'll do more processing for the label and the subsequent authentication.
And what did I gain in doing this added work compared to not sending the
R-P header Invite?  Nothing.  I'm going to have a fun time explaining
that to my guy who has written code to support the previous versions of
the draft that he is going to write additional code that amounts to no
gain.

In fact, in thinking about this, it will be code that will never be used
in our client using a namespace to support the NS/EP codepoint.  The
trigger for our SIP R-P client is a particular phone number sequence.
Absence of that sequence means that all other calls from that client are
regular SIP messages.

> I think the age old practice of being conservative in what you send
> applies to what we say to each other, not what signaling is sent by
> telecommunications devices :>}

agreed on the former, but Postel applied it to the latter and drilled it
into many a head, who in turn continued the drilling :-). (note, the
full quote is be liberal in what you accept, and conservative in what
you send, see rfc-760)

> Explain how one would signal the NS/EP codepoint case with only one
> value (which is the default).

You already have.  And I've added a case in point where the "off" value
will never see light of day.

As a side note, this issue has been discussed in the past on a different
list, so there is a reason why the draft has taken the position not
requiring at least 2 values per namespace.  My desire is to defend the
current position, but the issue is not critical, so I will not add any
other comments on the matter on the list.

Regards,

-ken

ps, it would be nice to see plain text messages rather than html marked
ones.

_______________________________________________
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: Janet P Gunn <[email-masked]>
Date: Fri, 16 Jan 2004 11:30:32 -0500

OK, now _I_ am confused.

You say "If a message (INVITE) is sent without an RP-header, it should be
treated by
the receiver as if it contained an RP-header with the default value for
that
namespace, that is, "ON"."

But  if the message does not contain the R-P Header, how do I even know
which namespace it (isn't) referring to.  Are you saying that if a  SIP
message contains no R-P Header, it should be assumed to be "the default"
for EVERY registered namespace? Or even for every namespace recognized by
that network? (This doesn't seem sensible, since the default value, and the
associated default behavior, are different for different namespaces.)

I understood the document to say that the default value is used when there
IS a R-P Header, and the header DOES contain the namespace, but DOES NOT
contain the value.

There is no one-to-one mapping between R-P namespaces and IP Administrative
domains.

 I understood that two (or more) R-P Header namespaces (with different
associated policies/behaviors) can be used in the same network, and even in
the same SIP message.

                                                                                                                                 
                      Mpierce1                                                                                                   
                      @aol.com                 To:      [email-masked], [email-masked]                                     
                      Sent by:                 cc:      [email-masked]                                                             
                      sip-admin                Subject: Re: [Sip] re: WGLC: resource priority (3)                                

                      01/16/2004 10:58                                                                                           
                      AM                                                                                                         

[MAP]
We must be talking about two different things or we have completely
different
understandings of what the draft RP-header doc means, which scares me. I
hope
someone else can examine this issue and help us resolve it.

If a namespace is defined with one single value of "ON", then that value
"ON"
must also be designated as the default.

If a message (INVITE) is sent without an RP-header, it should be treated by

the receiver as if it contained an RP-header with the default value for
that
namespace, that is, "ON".

There is then no way to signal any other value (e.g.,"OFF") for this
namespace since no other value is defined in the IANA registration. The
absence of
"ON" is not "OFF" since these are defined in IANA as text strings, not a
boolean.
"OFF" simply does not exist for this namespace.

I don't understand the argument about saving (a trivial) amount of code (to

recognize the "OFF" value). It seems to me that any implementation should
be
able to handle the case of multiple priority values (e.g., 5 for DOD), so
the
code to recognize 2 must already be there.

What I always learned when defining protocols is that it is always best to
be
explicit in what you send, so that the receiver does not have to infer or
guess or assume what was really meant.

Mike Pierce

---

From: [email-masked]
Date: Fri, 16 Jan 2004 10:58:04 EST

[MAP]
We must be talking about two different things or we have completely different 
understandings of what the draft RP-header doc means, which scares me. I hope 
someone else can examine this issue and help us resolve it.

If a namespace is defined with one single value of "ON", then that value "ON" 
must also be designated as the default.

If a message (INVITE) is sent without an RP-header, it should be treated by 
the receiver as if it contained an RP-header with the default value for that 
namespace, that is, "ON".

There is then no way to signal any other value (e.g.,"OFF") for this 
namespace since no other value is defined in the IANA registration. The absence of 
"ON" is not "OFF" since these are defined in IANA as text strings, not a boolean. 
"OFF" simply does not exist for this namespace.

I don't understand the argument about saving (a trivial) amount of code (to 
recognize the "OFF" value). It seems to me that any implementation should be 
able to handle the case of multiple priority values (e.g., 5 for DOD), so the 
code to recognize 2 must already be there.

What I always learned when defining protocols is that it is always best to be 
explicit in what you send, so that the receiver does not have to infer or 
guess or assume what was really meant.

Mike Pierce

---

From: [email-masked]
Date: Fri, 16 Jan 2004 14:07:23 EST

In a message dated 1/16/2004 11:28:02 AM Eastern Standard Time, 
[email-masked] writes:

[JG]
OK, now _I_ am confused.

[MAP] Yes, that is what I'm saying. Namespaces aren't some arbitrary things 
that just may or may not be present at random. Any device that might possibly 
react to the priority value of a namespace (or the default implied by its 
absence), must have an awareness of all the namespaces it needs to be concerned 
with. It must ignore all others, since they are meaningless. For the namespaces 
that it must be concerned with for a call setup, it must have a value to 
associate with each, even if derived by default. For Ken's apparent case where the 
defined value of "ON" means to use the NS/EP codepoint of T1.631, then the 
default (when nothing is specified as in 99.9999% of the calls) is to default to 
"OFF" for this namespace. If a device doesn't understand the need to default 
the namespace to "OFF", then it also could not know what "ON" means. This 
requires defining a namespace with two values, "ON" and "OFF", with "OFF" as the 
default. There is no way to do this with only one value ("ON") defined in the 
IANA registration. I agree with Ken's "be conservative in what you send" idea, 
that an implementation would never send an RP-header containing "OFF" for this 
namespace, but it still must be registered and receivers must be able to 
understand it ("be liberal in what you accept"). As Rohan says "Just because you 
normally don't send the value "off" doesn't mean it doesn't exist."

[JG]

[MAP] The draft only says "in the absence of the priority value", which you 
could read to mean what you said above. I read it to mean any condition in 
which the priority value is not available, including the absence of the header, 
which I expect to be the way to code the message for the majority of calls that 
want the default value (as explained above). As I read the ABNF, the priority 
value can not be left out if a namespace is specified.

[JG]

[MAP] Yes, but the draft intentionally does not talk about the interaction 
between them. Each is treated separately.

Mike Pierce