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

Colin Perkins <csp@csperkins.org> Mon, 24 July 2006 22:15 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G58i9-0003hC-1Y; Mon, 24 Jul 2006 18:15:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G58i7-0003gL-N6 for mmusic@ietf.org; Mon, 24 Jul 2006 18:15:35 -0400
Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G58i6-0007Ue-8J for mmusic@ietf.org; Mon, 24 Jul 2006 18:15:35 -0400
Received: from csperkins-dsl.demon.co.uk ([62.49.4.249]:61985 helo=[192.168.0.3]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1G58i5-000744-HP; Mon, 24 Jul 2006 23:15:33 +0100
In-Reply-To: <CCEIKIABCPCLIACIPNMKIECECGAA.gunnar.hellstrom@omnitor.se>
References: <CCEIKIABCPCLIACIPNMKIECECGAA.gunnar.hellstrom@omnitor.se>
Mime-Version: 1.0 (Apple Message framework v752.2)
X-Priority: 3 (Normal)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <F313A412-DE37-43BA-99D9-B544AEDEEEA8@csperkins.org>
Content-Transfer-Encoding: 7bit
From: Colin Perkins <csp@csperkins.org>
Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-04.txt
Date: Mon, 24 Jul 2006 23:15:28 +0100
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: mmusic@ietf.org
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org

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
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic