draft-ietf-sipping-media-policy-dataset: zero children of an element

[Worley, Dale R (Dale)]

In a number of places, draft-ietf-sipping-media-policy-dataset-10 specifies that one element must have one or more children of a particular type. In many of these cases, having zero children would have a well-defined meaning. And in various situations, it is difficult to define appropriate processing without allowing zero children. I am proposing that we modify the draft to admit zero children whenever this has a well-defined meaning.

The two cases I've identified so far are:

A <streams> element with zero <stream> children, indicating a session with no media streams. This is needed to be able to encode SDP descriptions that contain zero m= lines (which is permitted by RFC 4566).

In various situations where a policy is specified, we need a way to specify that no value of a particular attribute is allowed. This describes a policy that accepts no media streams, which can happen if two policies are merged that have no overlap. Without this change, one would not be able to express the conjunction of two incompatible policies at all.

Comments?

Dale
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[DRAGE, Keith (Keith)]

Isn't this the standard database mantra where no entry is different from "0".

We should surely be using two different values to identify these distinct concepts.

Keith

> -----Original Message-----
> From: rai-***@ietf.org [mailto:rai-***@ietf.org] On
> Behalf Of Worley, Dale R (Dale)
> Sent: Wednesday, December 08, 2010 6:58 PM
> To: ***@ietf.org; ***@ietf.org
> Subject: [RAI] draft-ietf-sipping-media-policy-dataset: zero
> children of an element
>
> In a number of places,
> draft-ietf-sipping-media-policy-dataset-10 specifies that one
> element must have one or more children of a particular type.
> In many of these cases, having zero children would have a
> well-defined meaning. And in various situations, it is
> difficult to define appropriate processing without allowing
> zero children. I am proposing that we modify the draft to
> admit zero children whenever this has a well-defined meaning.
>
> The two cases I've identified so far are:
>
> A <streams> element with zero <stream> children, indicating a
> session with no media streams. This is needed to be able to
> encode SDP descriptions that contain zero m= lines (which is
> permitted by RFC 4566).
>
> In various situations where a policy is specified, we need a
> way to specify that no value of a particular attribute is
> allowed. This describes a policy that accepts no media
> streams, which can happen if two policies are merged that
> have no overlap. Without this change, one would not be able
> to express the conjunction of two incompatible policies at all.
>
> Comments?
>
> Dale
> _______________________________________________
> RAI mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/rai
>
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP

[Worley, Dale R (Dale)]

> From: DRAGE, Keith (Keith) [***@alcatel-lucent.com]
>
> Isn't this the standard database mantra where no entry is different from "0".
>
> We should surely be using two different values to identify these distinct concepts.

The situation is that we cannot denote a set with no elements. It's not very useful to write a policy that uses such a set, but it's easy to generate such a policy when you combine two policies.

Dale
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-***@cs.columbia.edu for questions on current sip
Use ***@ietf.org for new developments of core SIP