Subject: [Sipping] petrie-sipping-profile-dateasets-02

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 29 Jul 2005 12:29:06 -0400

The whole merge framework has both positive and negative permissions that it
trying to merge in a very abstract way. I think this is going to be
impossible and results in things that are very hard to understand what they
mean; furthermore, I don't think it is needed to solve any of the problems
at hand.

The policy element actually makes no sense to me - take for example UDP 5060
is allowed. Does this mean UDP 5070 is not? if this line was not there (and
there was no disallow) would it mean that the UA should not try this even if
DNS SRV said to try it? Some things are settings, like use this server as
your stun server. Some things are constraints, like max_bandwith or allowed
port range. This confuses the two. All of them can only be merged in a way
that dependent on the data. And is not a big deal that the device has to
understand the data to merge it because it can only use data that it
understands anyway.

more minor things ...

I don't really agree with some of the requirements and text in the use cases
but that is all probably irrelevant. On the broad level it makes sense so
the meat of the document is probably more important to comment on ....

Visibility concept is somewhat like setting the evil bit but I don't care if
it stays or goes. Security section needs to clearly outline that it is
unenforceable.

The q preference is really problematic as a general thing. If the DNS
provides some q preference and this provides some q values how do they
interact? You can't solve this in the general case. My recordation is make
it so that this is *not* something everything has and instead, specific
profiles for specific items can add a q value for the items where it makes
sense and they can define how to use it.

The direction attribute makes no sense except for media - move it to the
media profile and don't try and define what sendonly AOR is.

The merge policy make sense - but you need to define what happens on
conflict. My preference would be just define a winner.

The exclude policy makes no sense to me for most things. Prefer to see it
just on specific containers where it is defined what it means.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP