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

"Desineni, Harikishan" <hdesinen@qualcomm.com> Tue, 25 July 2006 00:19 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5AeA-0000AB-G1; Mon, 24 Jul 2006 20:19:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5Ae9-00008p-0g for mmusic@ietf.org; Mon, 24 Jul 2006 20:19:37 -0400
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5Ae6-0007uH-F2 for mmusic@ietf.org; Mon, 24 Jul 2006 20:19:36 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6P0JVU3024014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Jul 2006 17:19:31 -0700
Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6P0JUDP015882; Mon, 24 Jul 2006 17:19:30 -0700 (PDT)
Received: from NAEX01.qualcomm.com ([129.46.51.61]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 17:19:30 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-04.txt
Date: Mon, 24 Jul 2006 17:19:29 -0700
Message-ID: <2CA3E1B6CEC064449CAA7D0FAB46079B01C0D4EE@NAEX01.na.qualcomm.com>
In-Reply-To: <F313A412-DE37-43BA-99D9-B544AEDEEEA8@csperkins.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-04.txt
Thread-Index: AcavbsaOLrtapvM4RxCLMZIkgeRArAADzFsQ
From: "Desineni, Harikishan" <hdesinen@qualcomm.com>
To: Colin Perkins <csp@csperkins.org>, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
X-OriginalArrivalTime: 25 Jul 2006 00:19:30.0657 (UTC) FILETIME=[FF5C1510:01C6AF7F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
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

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:hd@qualcomm.com

 

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org] 
> Sent: Monday, July 24, 2006 3:15 PM
> To: Gunnar Hellstrom
> Cc: mmusic@ietf.org
> 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
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic