Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05: session-level attributes

[Paul Kyzivat <[e-mail]>]

On 12/29/12 6:03 PM, Ali C. Begen (abegen) wrote:
> I don¹t remember us reaching a consensus regarding the text proposed by
> Brett. One thing certain is that we don't wanna break anything that
> complies with 4566 but we should also make the text as clear as possible.
>
> I am OK with Brett's suggestion as I don't recall an attribute like what
> Paul might have seen. But, even if such an attribute exists, the current
> text would be incorrect, too (This would indicate a problem with that
> particular attribute not 4566 or 4566bis).

I found one: a=maxprate in RFC3890.

	Thanks,
	Paul

> Brett's proposal does not make the text any worse. So, I am planning to
> incorporate this change.
>
> Any objections?
>
> -acbegen
>
> -----Original Message-----
> From: Paul Kyzivat <[e-mail]>
> Date: Monday, August 27, 2012 12:03 PM
> To: "[e-mail]" <[e-mail]>
> Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05:
> session-level attributes
>
>  >I've always thought this should be the way things work, for all
>  >attributes. But somewhere I came across an attribute (sorry, don't
>  >remember which one) where the attribute at session level means something
>  >different than the attribute at media level, and so can't be treated as
>  >a default for media level. (E.g. the session level is an aggregate limit
>  >for something, while the media level is a limit for a single m-line.)
>  >
>  >Am I just dreaming this? Or can someone identify specific attributes
>  >that behave this way?
>  >
>  >If there are existing attributes that behave this way, then we can't
>  >make a blanket statement like this. There will need to be an escape
>  >hatch. For example:
>  >
>  >"The connection ("c=") information in the
>  > session-level section applies to all the media of that session unless
>  > overridden by connection information
>  > in the media description. For instance, in the example
>  > below, TBD..."
>  >
>  >"The attribute ("a=") information in the
>  > session-level section applies to all the media of that session unless
>  > overridden by connection information or an attribute of the same name
>  > or choice in the media description, or the specification of that
>  > attribute calls for a different treatment.
>  > For instance, in the example
>  > below, each media behaves as if it were given a "recvonly" attribute.
>  > If the example had additionally contained a "sendrecv" media-level
>  > attribute for audio, only the video media would behave as if it were
>  > given a "recvonly" attribute."
>  >
>  >Even this could have some backward compatibility consequences. I think
>  >there are some attributes that are only defined for media level. This
>  >revision would mean that a session level value could override a default
>  >for media level. Implementations that aren't prepared for that might
>  >break.
>  >
>  > Thanks,
>  > Paul
>  >
>  >On 8/27/12 12:04 PM, Ali C. Begen (abegen) wrote:
>  >> Brett suggested the following change in the SDP draft. Any objections?
>  >>
>  >> -acbegen
>  >>
>  >> Current text:
>  >>
>  >> "The connection ("c=") and attribute ("a=") information in the
>  >> session-level section applies to all the media of that session unless
>  >> overridden by connection information or an attribute of the same name
>  >> in the media description. For instance, in the example below, each
>  >> media behaves as if it were given a "recvonly" attribute."
>  >>
>  >> Proposed text:
>  >>
>  >> "The connection ("c=") and attribute ("a=") information in the
>  >> session-level section applies to all the media of that session unless
>  >> overridden by connection information or an attribute of the same name
>  >> or choice in the media description. For instance, in the example
>  >> below, each media behaves as if it were given a "recvonly" attribute.
>  >> If the example had additionally contained a "sendrecv" media-level
>  >> attribute for audio, only the video media would behave as if it were
>  >> given a "recvonly" attribute."
>  >>
>  >>> -----Original Message-----
>  >>> From: Brett Tate [mailto:[e-mail]]
>  >>> Sent: Wednesday, August 08, 2012 7:54 AM
>  >>> To: Ali C. Begen (abegen); [e-mail]
>  >>> Subject: RE: Draft-ietf-mmusic-rfc4566bis-05: session-level attributes
>  >>>
>  >>>>> Draft-ietf-mmusic-rfc4566bis-05 section 5 indicates the
>  >>>>> following.
>  >>>>>
>  >>>>> "In general, session-level values are the default for all
>  >>>>> media unless overridden by an equivalent media-level value."
>  >>>>>
>  >>>>> "The connection ("c=") and attribute ("a=") information
>  >>>>> in the session-level section applies to all the media of
>  >>>>> that session unless overridden by connection information
>  >>>>> or an attribute of the same name in the media description.
>  >>>>> For instance, in the example below, each media behaves
>  >>>>> as if it were given a "recvonly" attribute."
>  >>>>>
>  >>>>> If the attributes are related but with different names
>  >>>>> (such as "inactive" and "sendrecv"), does the attribute
>  >>>>> at the media-level have precedence over the value at the
>  >>>>> session-level? If so, I recommend that the draft be
>  >>>>> updated to clarify the topic.
>  >>>>
>  >>>> I believe so. at least that is my understanding from the
>  >>>> text. Does it really need clarification? Thoughts?
>  >>>
>  >>> I think that it should be clarified because it is unclear if "an
>  >>>attribute of the same name" indicates the typical situation or only
>  >>> situation concerning application of "unless overridden by an
>  >>>equivalent media-level value". For instance if I sent "a=inactive"
>  >>> at session-level and "a=sendrecv" at media-level, I'd be concerned
>  >>>that the receiver may interpret the SDP as being
>  >>> abnormal (such as including both values at media-level) instead of
>  >>>allowing "a=sendrecv" to override "a=inactive".
>  >>>
>  >>> In case it matters from an extendibility perspective, requiring the
>  >>>same name might make it easier to recognize the override.
>  >>> However since section 6 already introduces complications with
>  >>>defaulting to "sendrecv" if a new option is defined/used and
>  >>> unknown, allowing the override even when the names are not the same
>  >>>doesn't make things too much worse; it actually
>  >>> allows communication of a backup attribute (such as "a=inactive") if
>  >>>they don't understand the preferred new attribute (such
>  >>> as "a=foo").
>  >>>
>  >>> "If none of the attributes "sendonly", "recvonly", "inactive",
>  >>> and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
>  >>> default for sessions that are not of the conference type
>  >>> "broadcast" or "H332" (see below)."
>  >>>
>  >>> Thanks for the response,
>  >>> Brett
>  >>
>  >> _______________________________________________
>  >> mmusic mailing list
>  >> [e-mail]
>  >> https://www.ietf.org/mailman/listinfo/mmusic
>  >>
>  >
>  >_______________________________________________
>  >mmusic mailing list
>  >[e-mail]
>  >https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic