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

From: [email-masked]
Date: Thu, 15 Jan 2004 20:03:08 EST

In a message dated 1/15/2004 5:12:56 PM Eastern Standard Time, 
[email-masked] writes:

> 
> I disagree on the latter part that every namespace must have two
> "priority" values.  If one has a binary "on/off" NameSpace Value, and
> the "off" means that the message is to be treated the same as if the R-P
> never existed, then I don't see why an additional Value must exist.  Its
> counter to the age old practice of be conservative in what you send.
> 
> An example of such a binary condition is if I wanted to have a namespace
> that mapped to the binary NS/EP codepoint of T1.631.
> 
> 

[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"). How would it be possible to signal the "off" value?

If one wants a "binary" on/off, then why not just define two values: ON and 
OFF with OFF as the default? Then either can be signalled, and the absence of 
the RP-header means OFF.

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 :>}

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

Mike Pierce

---

From: "Ken Carlberg" <[email-masked]>
Date: Fri, 16 Jan 2004 08:19:22 -0500

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

> that the draft states: 
> 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

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 16 Jan 2004 09:34:36 -0800

Ken,

Just because you normally don't send the value "off" doesn't mean it 
doesn't exist.

thx,
-r