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

In line

Janet

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

>    From: "Attila Sipos" <attila.sipos@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@a.com calls B@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@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip