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

From: "Even, Roni" <[email-masked]>
Date: Tue, 1 Aug 2006 08:56:28 +0300

Gunnar,

See in line
Roni

> -----Original Message-----
> From: Gunnar Hellstrom [mailto:[email-masked]]
> Sent: Tuesday, August 01, 2006 1:01 AM
> To: Colin Perkins
> Cc: [email-masked]
> 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
> [email-masked]
> Mob: +46 708 204 288
> Phone: +46 8 556 002 03
> www.omnitor.se
> 
> 
> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Monday, July 24, 2006 11:15 PM
> To: Gunnar Hellstrom
> Cc: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

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

---

From: "Guido Gybels" <[email-masked]>
Date: Wed, 9 Aug 2006 08:50:49 +0100

Hi Colin,

Thanks for the reply.

<<This is where I disagree. The content is a conversation; the fact  
that one of the participants is using a text phone is an orthogonal  
issue. Depending on how I use the text phone, the content can change,  
but the fact that it's a text phone can't.>>

Please forget about textphones, they should never have been brought into the debate, because they confuse the matter.

What we want to signal is a type of real-time text conversation as used by deaf people (whether or not textphones are par of it is frankly irrelevant). "txp" would signal that.

The reason this is NOT just another type of real-time text is that in this community they use a number of different conventions while having these conversations, including the use of GA in band for turn taking or SKSK for example.

I simply would like to be able to signal THAT type of text conversation, for which it seems reasonable to use "txp".

I believe that fully meets the logical and semantic framework for "content".

The debate has been muddled, not in the least because it is hard for hearing people to understand this particular way in which deaf people have been using text for so long.

Best wishes,

Guido

Guido Gybels
Director of New Technologies

RNID, 19-23 Featherstone Street
London EC1Y 8SL, UK
Tel +44(0)207 294 3713
Fax +44(0)207 296 8069 

Want to win and help RNID?
Support RNID by playing monday - the Charities Lottery.
With 27 times better chances of winning, monday could change your life.
And you'll help us raise £3,000,000 for our work to change the world for deaf and hard of hearing people.
Play online at www.playmonday.com

This email and attachments (if any) must be swept for viruses before opening. Their contents may be confidential or privileged and are intended solely for the named recipient. If you are not the intended recipient and you have received this email in error you must not read or use this email and should notify RNID on: +44 (0) 20 7296 8000.

RNID, Registered Office 19-23 Featherstone Street, London EC1Y 8SL No. 454169 (England, Registered Charity No. 207720).