Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-04.txt

["Frank Shearar" <[e-mail]>]

>From the draft's section 1:

   The 'content' attribute is needed, so that the
   receiving application can treat each media stream appropriately based
   on its content.

The word "user" isn't mentioned here. So I figure that, from reading the
draft, the "content" attribute doesn't tell users what to do, or suggest
appropriate behaviour.

Thus, it seems like txp and user-floor are in the same boat: both hint that
users might require turn-taking, or other behavioural changes.

I thus submit that if txp goes (and is written up in a separate draft, like
Colin's "strawman" draft), then user-floor must go too, again into a
separate draft. (Or maybe "behavioural hints" attributes could go together
in their own draft or something.)

frank

"Gunnar Hellstrom" <[e-mail]> wrote:

> I have re-read the intention of the content attribute and cannot find that
> there is any apparent difference between the currently included values
that
> make any of them contribute to "overloading".
>
> This is what the draft says:
> "The 'content' attribute is needed, so that the
>    receiving application can treat each media stream appropriately based
>    on its content."
>
> One example taken is to place the main video stream in a big video window.
>
> It does not say exactly what feature of the content that shall be
expressed
> by an attribute, and the already coded examples show various features:
>
> "slides" /  indicates that the medium contains images. Hints the user to
> view this window in combination with the speaker or main view.
>
>  "speaker" / Indicates that this is a view or sound or typing of the
> speaking part in a call or conference. Hints a user to concentrate on
> language output from it.
>
>  "sl" /     indicates type of language used.  A user gets a hint that sign
> language capability is expected to understand it. If it is a
conversational
> session, sign language capability may be required to respond as well.
>
>  "main"     indicates some kind of level of importance or position in
> session structure. Hints the user to pay a lot of attention here.
>
> / "alt" /   indicates also some kind of level of importance or other way
to
> express things.
>             gives a hint to the user that it is of lower priority but may
be
> very useful if you have any problems with the main.
>
>  "user-floor" / Indicates that all see each other or hear each other or
see
> each other?s typing intermixed, and hints the user that formal turntaking
> habits are required in the media channel.
>
> "txp" Indicates that transmission to the party will be intermixed with
media
> coming from the party, and hints the user that formal turntaking habits
are
> required in the media channel.
>
>
> Are they not all a suitable mixture of indications of source of contents,
> media format of the contents, expectations on UA treatment of the contents
> and expectation of the user receiving the contents?
>
> And the idea being that they are a set of registered values so that they
can
> be discriminated by the UA and acted on consistently.
>
> "subtitles" could be a suitable extension. I do not propose that at the
> moment, but would support it if anyone wanted. It would mean text
> translating spoken content in a streaming video/audio combination. No
> interaction would be expected from the user.
>
> Your examples "subtitles in french" and "subtitles in spanish" would
instead
> use a combination of "subtitles" and the "language tag" attribute in order
> to maintain the goal of being decodable by automata.
>
> Agree?
>
> Gunnar
> --------------------------------------------------------------------------
--
> -
> Gunnar Hellstrom, Omnitor
> [e-mail]
> Mob: [phone]
> Phone: [phone]
> www.omnitor.se
>
>
> -----Original Message-----
> From: Desineni, Harikishan [mailto:[e-mail]]
> Sent: Tuesday, July 25, 2006 1:19 AM
> To: Colin Perkins; Gunnar Hellstrom
> Cc: [e-mail]
> Subject: RE: [MMUSIC] I-D
> ACTION:draft-ietf-mmusic-sdp-media-content-04.txt
>
>
> The definition of "User-floor" doesn't appear to be really capturing the
> content of the stream. It looks like a way of signaling the application
> behavior, which should probably be not done using "content" attribute.
>
> >From the description (previous and newly proposed one), it does not look
> like "txp" is capturing the content of the stream. "txp" is giving an
> impression that "content" attribute is overloaded. It is not impacting
> any call negotiation and at the same time it is not really capturing the
> content of text stream.
>
> "content" attribute should not be overloaded to achieve a specific
> behavior at the UI/Application level. And I think that "user-floow" and
> "txp" are are not capturing the content.
>
> Examples of meaningful text stream content description which I can think
> of: Stock ticker, breaking news headlines, subtitilse in spanish,
> subtitiles in french.
>
> - - - - - - - - - - - - - - - - - -
> Harikishan Desineni
> Qualcomm Inc.,
> mailto:[e-mail]
>
>
>
> > -----Original Message-----
> > From: Colin Perkins [mailto:[e-mail]]
> > Sent: Monday, July 24, 2006 3:15 PM
> > To: Gunnar Hellstrom
> > Cc: [e-mail]
> > Subject: Re: [MMUSIC] I-D
> > ACTION:draft-ietf-mmusic-sdp-media-content-04.txt
> >
> > Gunnar,
> >
> > On 24 Jul 2006, at 22:42, Gunnar Hellstrom wrote:
> > > The device in the far end, on the other end of the PSTN line on the
> > > other side of a gateway MAY have presentation limitations.
> > >
> > > But it MAY also have no limitations.
> > >
> > > The important thing is that it operates in an environment
> > where there
> > > is a habit to do formal turntaking by text tokens in the
> > text stream.
> > > Our user will have a better chance to use the media properly when
> > > knowing that that is the environment it comes from.
> > >
> > > The IP terminal does not need to adapt more than to give this
> > > indication in some way to the user.
> >
> > You have said that before, and I have previously explained
> > that it is a form of device capability negotiation, and
> > therefore outside the scope of a content label.
> >
> > > Similarly to the other content indicators.
> > > The user-floor is a total analogy. The user needs an
> > indication about
> > > how to behave when using the medium. It is because of a lack in the
> > > far end terminal or in the conference system. The terminal does not
> > > adapt more than give an indication. Similar as for "txp".
> >
> > That is a problem with user-floor.
> >
> > > For the "sl" indicator, for sign language, it is important
> > to present
> > > it big enough and with proper quality to be perceived. That might
> > > influence terminal, but I suggest we do not use this indication for
> > > that purpose, but rather just for planning the layout on
> > the display
> > > and possibly to remind the user to prepare for a return channel in
> > > sign language.
> > >
> > > You say: "There is a significant difference: the txp parameter
> > > requires the user to change their behaviour due to device
> > > capabilities. None of the others do." It is a combination of
> > > conversational behaviour culture and far far end device
> > limitations on
> > > some of the terminals.
> > > All parameters have something specific. Why would this be forbidden?
> >
> > Because the other parameters, with the possible exception of
> > user- floor, do not require changes in user behaviour.
> >
> > > The sl requires video capabilities in the far end terminal.
> > > The user-floor indicates a lack of conferencing tools.
> > > The slides indicate a capability to send pictures.
> > >
> > > New extensions may add yet other parameters that indicate specific
> > > characteristics of the terminals transmitting them combined with an
> > > indication of the resulting medium.
> >
> > No, they may not. This is your fundamental misunderstanding:
> > they label the content of the stream, not the characteristics
> > of the terminal. There is an important difference, which you
> > do not seem to understand.
> >
> > > How about to add a new value "subtitles" to be used as an
> > indication
> > > for the receiving application to plan the layout to present
> > it as text
> > > placed under the main video window.
> >
> > Sure, that makes sense, since it labels the content of the
> > stream, and does not describe the capabilities of the device.
> >
> > > You say "For the record, I disagree that the changes suggested are
> > > sufficient, for the reasons I have explained."
> > >
> > > I understand this as  "OK, let it be accepted but remember
> > I was not
> > > totally happy with it".
> >
> > No, it means that the changes you have proposed ignore my
> > concerns, and hence I object to the publication of the draft
> > as it stands.
> >
> > Colin


_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic