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

[Gunnar Hellstrom <[e-mail]>]

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
>




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