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

[Gunnar Hellstrom <[e-mail]>]

I know it is very late in the process for the media-content draft. It is in
AD evaluation state.
But I have a couple of comments that I hope can be considered while it is
still discussed.

1. In section 10, IANA Considerations, there is this line:

"speaker  RFC xxxx  Image from the speaker"

I think it should be:

"speaker  RFC xxxx  Media from the speaker"

The reason is to make it match the statement in section 5:

"All of these values can be used with any media type."

2. Is the statement "All of these values can be used with any media type."
really needed?
Today, with some flexible mind you can imagine all current content types be
used with all media types. Even for "slides" I can imagine an audio stream
describing the slides, a series of images, a video, and a set of text lines
being the slides.
But if a new extension shall be registered, is there really something in the
logic of the use of the attributes that make it important that it can be
used with any media?
If I want to register "colour correction chart", it is very hard to imagine
an audio representation of it.
What is your view, should that sentence in section 5 be changed to:
"The ambition is to express general content values so that they can be used
with any media type."

3. Is the extension possibilities enough described?
In the evaluation comments it is requested to improve the description about
how IANA is expected to handle registrations of new values.
I do not see anything mentioned in section 10 about the extesnion mechanism.
I suggest that a sentence about that is added.

Gunnar
----------------------------------------------------------------------------
-
Gunnar Hellstrom, Omnitor
[e-mail]
Mob: [phone]
Phone: [phone]
www.omnitor.se


-----Original Message-----
From: Colin Perkins [mailto:[e-mail]]
Sent: Monday, July 24, 2006 11: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