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

["Even, Roni" <[e-mail]>]

Gunnar,

See in line
Roni

> -----Original Message-----
> From: Gunnar Hellstrom [mailto:[e-mail]]
> Sent: Tuesday, August 01, 2006 1:01 AM
> To: Colin Perkins
> Cc: [e-mail]
> Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-
> 04.txt
> 
> 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."


[RE:] I think this makes sense but this means that the text in section 5
"speaker: This is a image ..." should be send to "This is a media". I
assume that the media is known from the m line

> 
> 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."


[RE:] I think that in general the statement that the attribute can be
used with any media type is correct, it may not make sense to use it.
Anyhow you can always know the media type from the m line. BTW, I do not
like your example since it describe the payload type and not what is the
content of the payload.

> 
> 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

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