Subject: RE: [MMUSIC] Accessibility related parameters in draft-ietf-mmusic-sdp-media-content-01.txt

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sat, 4 Mar 2006 00:08:44 +0100

Jani,

I think the logic around these media-content parameters need to be
straightened up if they are to have any real value.

In section 10, IANA considerations, you have the table of where the values
are defined, that is supposed to be stored in an IANA registry. That is an
excellent idea.

Then you say that you want the table to point to your media-content
specification for the definition of "txp" and the other proposed values.

But then, when I propose refining of the definition of the meaning of "txp"
you say that it does not belong to the media-content specification, but can
be defined somewhere else.

If you do not want to have enough application definition of the parameters
in the media-content specification, I think we need to create yet another
mechanism for IANA registration of further parameter information. But then
the whole thing starts to become too heavy.

When you defined the user-floor parameter, you included enough information
about its intention:
"user-floor: This indicates that a user level floor control is
      required.  In other words, this is meant for system without any
      mechanism for floor control, and where a human needs to figure out
      whether an act of floor control, e.g., saying 'over', is needed or
      not.  Typical use case for this is e.g., a situation where the
      other endpoint of the connection is a walkie-talkie type of
      device."

It is true that it does not say how the terminal shall act when it gets the
user-floor indication, but it says what application it is intended to have.

Why do you not like to have an application description on a similar level
for the half duplex textphone indication?
If we leave it open without any indication about the application meaning of
the value and do not register a pointer to where it is more defined, we will
leave it open for anarchy. One designer will use the indicator for when he
lets textphone tones be carried in the audio channel ( I hope it never
happens) , another may want to indicate that the textphone has the severely
restricted character repertoir of the US Baudot TTY textphones, and a third
want to indicate that the call may alternate between text and voice.

I suggest that we book this "txp" parameter to mean a connection with a
textphone with the display arranged for half duplex operation that makes
formal turntaking required. And we add some words about that in the
media-contents draft to bring the description of "txp" up to the same level
as the "user-floor" parameter.

If, in the future, someone want to add other textphone-related parameters,
it is just to describe it in an RFC and extend the IANA registered table
moved from section 10.

So, again, I try something explaining, but less application-oriented as
definition of "txp".
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   txp:
   This indicates that the media stream is originated from a textphone,
   and it requires special behavior from the receiving application.
   Typical use case for this is e.g., a connection where one endpoint is
   an analog textphone of a kind that cannot handle two-way
   simultaneous text communication, and the other one is a native IP
   based real time text capable terminal. The human normally needs
   to apply formal turntaking habits, and need to figure out to what
   extent it is possible to interrupt the other part if needs arise.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
With that I think you have a definition on equal level as the user-floor
description that is of value for the application, and other aspects may
register their own values in the IANA registry.

OK?

Gunnar

----------------------------------------------------------------------------
-
Gunnar Hellström, Omnitor
[email-masked] <mailto:[email-masked]>
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se <http://www.omnitor.se>

-----Original Message-----
From: Jani Hautakorpi (JO/LMF) [mailto:[email-masked]]
Sent: Tuesday, February 28, 2006 3:25 PM
To: Gunnar Hellstrom
Cc: Arnoud van Wijk; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Accessibility
relatedparametersindraft-ietf-mmusic-sdp-media-content-01.txt

Hi Gunnar,

Gunnar Hellstrom wrote:
> Arnoud,
> OK, you are right. The txp content indicator is used for indicating
> limitations in media handling. The gateway should know, and send the txp
> indicator only in calls where there are limitations.
> So for a call with a V.18 capable gateway to a V.18 textphone, the
indicator
> should not be used and the SIP client should use a user interface that
> encourages two way simultaneous typing.
>
> I agree, and then want to ask Jani to take in this extended description of
> txp in the media-content specification:
>
> Typical use case for this is when there are presentation or communication
> limitations in the capability to handle simultaneous communication in both
> directions. This can for example be a connection where one endpoint is an
> analog textphone of the common types that requires turn-taking control by
> the user, and the other one is a native IP based text telephone.
> The user should be made aware that such limitations prevail.

Now the text in the draft is:

   txp:
   This indicates that the media stream is originated from a textphone,
   and it requires special behavior from the receiving application.
   Typical use case for this is e.g., a connection where one endpoint is
   an analog textphone, and the other one is a native IP based real time
   text capable terminal.

First you proposed that the following sentence should be added "The user
should be made aware that presentation and communication limitations
exist". This is application behavior, and we don't want to standardize
that. If the application supports "txp" draft, it will do it anyway.

Can you *briefly* answer what is wrong with the current text and why it
needs to be changed? The reason why I'm asking is that the only
difference I can see is the "application must inform the user" part.

As I have said before, I encourage you to specify the usage of "txp"
value on some other draft, if you want.

--
Jani

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

---

From: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Mon, 06 Mar 2006 10:04:03 +0200

> So, again, I try something explaining, but less application-oriented as

I think that the text you proposed is ok. I added it to the draft. The 
main problem I had with your previous proposal was the sentence "The 
user should be made aware that presentation and communication 
limitations exist".

Good that we could get to an agreement!

-- 
Jani

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Mon, 6 Mar 2006 09:13:37 +0100

Jani,
Thanks.
Gunnar.

-----Original Message-----
From: Jani Hautakorpi (JO/LMF) [mailto:[email-masked]]
Sent: Monday, March 06, 2006 9:04 AM
To: Gunnar Hellstrom
Cc: Arnoud van Wijk; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Accessibility related parameters in
draft-ietf-mmusic-sdp-media-content-01.txt

-- 
Jani