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

[Paul Kyzivat <[e-mail]>]

Inline.

On 12/29/12 7:45 PM, Ali C. Begen (abegen) wrote:
> 
> 
> -----Original Message-----
> From: Paul Kyzivat <[e-mail]>
> Date: Saturday, December 29, 2012 7:36 PM
> To: "[e-mail]" <[e-mail]>
> Subject: Re: [MMUSIC] Draft-ietf-mmusic-rfc4566bis-05:
> session-level attributes
> 
>  >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.

> Well, I still don't see a problem in replacing the current text with the
> proposed text. Do you?

Yes - I do see a problem.

I wish I didn't. IMO it was intended to work this way.
(The text we are proposing to revise was present in RFC2327.)
But it is a little bit confusing when you start to talk about attributes
that are session-only, or are explicitly defined for both session and
media level, as maxprate is.

ISTM that one way to move forward while retaining backward compatibility
is to make clear that this only applies to attributes defined as valid
for both session and media level, and and that has no special syntax or
semantics defined for session level.

But even this is a bit of a risk for backward compatibility, because
some existing implementations may not work this way. I'm ambivalent
about whether to take the hit on this. We could argue that such
implementations have always been  broken.

I'll also note that of the attributes defined in this draft, the only
ones defined as both media and session level are
sendrecv/sendonly/recvonly/inactive, sdplang, and lang. So these are the
only ones eligible to be used in an example here. And all of these have
special issues that make them bad examples:

The sendrecv, sendonly, ... attributes override each other: a sendonly
at media level overrides sendrecv at session level. This requires
special per-attribute description of the interaction between session and
media level, so they aren't a good example for the general override
principle. (The descriptions of these in section 6 should be updated to
discuss this.)

And a=lang and a=sdplang may appear multiple times to specify multiple
languages. E.g. suppose I have:

      a=lang:en
      a=lang:fr
      m=audio 49170 RTP/AVP 0
      m=video 51372 RTP/AVP 99
      a=lang:de

Presumably this means the audio has both English and French.
But oes the "a=lang:de" *override* those?
Or does it add a third language for the video stream?

ISTM that the specifications of these in section 6 need to be beefed up
to make this clear.
And once they are, they probably preempt the default rule.

And once that is done, we have no attributes defined at both media and
session level that are good to use in an example of the general
principle of session level providing a default for media level.
(Certainly there are others, but they aren't defined in this document.)

Now we *could* say this session-level default rule also applies to
attributes that are defined as media-level-only attributes. But then I
think we would incur a significant backward compatibility issue. (E.g.
if I use a=rtpmap at session level.)

I had hoped to provide some alternative wording here, but now I don't
think I'm ready to do that.

I think this needs more discussion, and we need to work out improvements
to the description of a=sendrecv, ... a=lang, ...
I am willing to take a crack at proposing new language for them, but
lets have this discussion play out first.

	Thanks,
	Paul

>  > 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
>  >
>  >_______________________________________________
>  >mmusic mailing list
>  >[e-mail]
>  >https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic