Re: [Sip] namespaces in RFC 4411, 4412 and draft-ietf-sip-rph-new-namespaces-00

[Janet P Gunn <jgunn6 at csc.com>]

In line

Janet

Dale.Worley at comcast.net wrote on 11/05/2007 05:04:11
PM:

>    From: "Attila Sipos" <attila.sipos at vegastream.com>
> 
>    Are namespaces just a way to group together different
users across
>    different DNS domains?
> 
>    What if a.com is using namespaces "dsn-000000"
to "dsn-000009"
>    and b.com is using the same namespaces?
>    Then if A at a.com calls B at b.com, wouldn't the namespaces
interfere?
> 
>    What looks after or checks the namespaces?
>    Is it that a proxy knows what everyone's namespace should
be?
>    So if someone wants to do "UA Preemption" and
tries to use a resource
>    priority level higher than they should have, then will
the domain's
>    proxy downgrade it back to the correct permitted level?
> 
> The primary thing is that resource-priority namespaces are registered
> with IANA (RFC 4412, section 3.1).
> 
> Within any administrative domain, if it processes resource-priorities
> at all, it will generally sanitize any incoming SIP messages to match
> the policy of the domain.  As a default, this means that it is
going
> to strip any resource-priority identification.  Above that, it
may
> respect resource-priority identification if the domain has a suitable
> working relationsip with the terminal or domain from which the message
> is entering -- but that relationship will explicitly or implicitly
> define how the resource-priority identifications will be preserved
or
> transformed at the boundary.

I am not so sure about that ( the stripping as a default).
 

I would think that (consistent with RFC 4412 
and RFC 3261)the default (when the edge device at
a new domain receives an 
RPH with an unrecognized namespace) would be to pass
and ignore the 
unrecognized name space. 

This is described in section 4.6.2 of RFC 4412:
"4.6.2.  No Known Namespace or Priority
Value

   If an RP actor does not understand any
of the resource values in the
   request, the treatment depends on the
presence of the 'Require'
   'resource-priority' option tag:

   1.  Without the option tag, the
RP actor treats the request as if it
       contained no 'Resource-Priority'
header field and processes it
       with default priority.
 Resource values that are not understood
       MUST NOT be modified or
deleted.

   2.  With the option tag, it MUST
reject the request with a 417
       (Unknown Resource-Priority)
response code.

   Making case (1) the default is necessary
since otherwise there would
   be no way to successfully complete any
calls in the case where a
   proxy on the way to the UAS shares no
common namespaces with the UAC,
   but the UAC and UAS do have such a namespace
in common.

   In general, as noted, a SIP request can
contain more than one
   'Resource-Priority' header field.  This
is necessary if a request
   needs to traverse different administrative
domains, each with its own
   set of valid resource values.  For
example, the ETS namespace might
   be enabled for United States government
networks that also support
   the DSN and/or DRSN namespaces for most
individuals in those domains."

Your suggested behavior would seem to violate this.

> 
> This is pretty much how *any* priority-identification system has to
be
> operated.
> 
> Dale
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip