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

["Ken Carlberg" <[e-mail]>]

> I would prefer a strict or semi-strict mode because these provide feedback in
> case: a) a misconfigured UA sends the wrong namespace.priority, and/or b)
> initial selection of a server/proxy that does not support the desired
> namespace.  The former is quite possible given an ability (and possibly,
> necessity) of the user to configure their own device to support the given
> namespace.value combination.
> 
> [JG] Before posting this, I checked with Dr. Fonash (head of NCS, which
> "owns" GETS and WPS).  He was very clear about wanting "If the SIP element
> does not recognize the namespace (wps or ets) it should pass it on without
> acting on it, rather than rejecting it."

ok.  Dr Fonash now has additional input on the subject given my previous email;
if there is no feedback, then the sender hopes everything is working fine.
further, it will continue to use an R-P capable proxy with no feedback from the
INVITE indicating that it does not support that particular namespace/value.  

Keep in mind that as it states earlier in the draft, the R-P header is ignored
(assuming proper implementation) by those proxies (eg, the installed base) that
do not support the new R-P header.  As a sidenote, our current implementation
of the R-P header follows the MAY portion of the draft and does not send back
hints of what are acceptable priorities.

Also, when you say the NCS "owns" GETS and WPS, are you refering to the systems
or the namespace?  If its both, then I have my doubts about the latter.  I see
no association of the NCS with WPS or GETS in the draft and it would seem that
initial "ownership" of those namespaces, as well as the others like ETS, lies
with the authors of the draft.  (I'll be happy to be corrected on that
assumption).

-ken


_______________________________________________
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