Re: [Slim] Last Call: <draft-ietf-slim-negotiating-human-language-06.txt> (Negotiating Human Language in Real-Time Communications) to Proposed Standard

[Gunnar Hellström <[e-mail]>]

The discussions after the LC seems to have ceased, and it would be good 
to come to conclusions on where we are with the 
draft-ietf-slim-negotiating-human-language and what the next steps are.

I have below made a summary of where we are in the discussions and in 
the text in version -08 of the draft. I hope this can help the process.

The IETF last call was issued on version -06 on 2017-02-06.

I issued a list of 8 observed issues in:
https://www.ietf.org/mail-archive/web/slim/current/msg00726.html
It was also accompanied by an edited draft.

so let us start with these issues and number the topics a - b- c this 
time, and then walking through all comments:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

*a) 1. Inexact wording about the syntax of the new attributes in Sections 
5 and 5.2.*
The optional asterisk was not shown in the syntax description early in section 5.2.
This lack was also noted by Dale Worley in the NITs summary for section 5.2 in:
https://www.ietf.org/mail-archive/web/slim/current/msg00766.html

The response was to delete the syntax presentation in section 5.2. I do not think that was the best solution because it was the only place where the syntax of the whole attribute was presented, but I have accepted it.
A number of other small issues with the syntax descriptions in 5.2 and 5.3 were noted and have been corrected in version -08.

The remaining issue is a minor one.

*Status: No conclusion yet if it was a good decision to delete the syntax 
description from section 5.2. *
--------------------------------------------------------------------------------------------------------------------------------

*b) 2. Reminiscense of earlier syntax.*
Also noted by Dale in the nits for section 5.2 in
https://www.ietf.org/mail-archive/web/slim/current/msg00766.html

*Status: This is sorted out in version -08*

----------------------------------------------------------------------------------------------------------

*c). 3. Inexact wording about O/A procedure in section 5.2*
The answers are called "accepted language", but within paranthesis it 
ismentioned that it is only in most cases that it is selected from 
theoffer. More suitable is then to just call it just "language": 
*Status: Sorted out in version -08* -----------------------------------------------------------------------------------------------

*d) 4. Inexact note at end of section 5.2.*

The note at end of 5.2 has a short discussion about accepted media as 
ifit should possibly be influenced by the matching languages.

*Status: Sorted out in version -08*

---------------------------------------------------------------------------------

*e)  5. Make use of the asterisk modifier on media level with session 
scope**also for media level purposes.*
The asterisk modifier optionally appended on attribute values has in 
theoriginal -06 draft only a session effect. Instead of specifying a 
separate session levelattribute, it is proposed that the asterisk gets 
an expanded definition,so that its placement conveys meaning of value 
for the successfullanguage negotiation.It has been discussed in the SLIM 
WG that the specification lacks twofunctions, required by the 
specifications by other bodies who arewaiting for the results of SLIM 
real-time work. (e.g. 3GPP TS 22.228 andETSI TR 103 201). 3GPP TS 22.228 
requires "The system should be able tonegotiate the user's desired 
language(s) and modalities, per mediastream and/or session, in order of 
preference." The most urgent of these functions can be fulfilled in a 
simple butsufficient way by extending the meaning of the asterisk. That 
is thepossibility to indicate a difference in preference between 
languages indifferent modalities.Earlier discussions on this topic has 
not resulted in a sufficientlysimple mechanism. The extended use of the 
asterisk proposed here isintended to introduce the required 
simplification, and yet meet the mosturgent needs.

The unusual definition of the asterisk parameter is also noted by Dale in
https://www.ietf.org/mail-archive/web/slim/current/msg00766.html
technical comment D, saying:
"the fact that the current proposal seems to require (but
does not directly specify) the coordinated absence/presence of an
asterisk on all of the repetitions of humintlang-send or
humintlang-recv is a warning that the syntax doesn't represent the
semantics as well as it might."

Doug Ewell asked if this was an effort to reopen an issue that the WG had rejected.
The question and its answer are seen in :
https://www.ietf.org/mail-archive/web/slim/current/msg00754.html
  
A dramatically reduced version of the proposal for the solution of indication of preference between languages in different media was introduced by me in item 12 of
https://www.ietf.org/mail-archive/web/slim/current/msg00786.html
saying:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
12.  5.3
-------------old text-----------------
5.3 No Language in Common
-------------new text----------------
5.3 Preference parameter
------------end of change 1 in 5.3---------------

-------------old text-in 5.3, secondparagraph-------------------------------
The mechanism for indicating this preference is that, in an offer, if
the last character of any of the 'humintlang-recv' or 'humintlang-
send' values is an asterisk, this indicates a request to not fail the call.
--------------------------new text-------------------------------
The mechanism for indicating this preference is that, in an offer, if
    the last character of any of the 'humintlang-recv' or 'humintlang-
send' values is an asterisk, this indicates a request to not failthe call.
The asterisk should be attached to attributes with languages of lower
preference to be matched if such difference can be specified. Thereby
the location of the asterisk can be used to support the decision on
which languages to use in the call.
---------------------------end of change 2 
in5.3--------------------------------------Motivation: There has not yet 
been any conclusion for my proposal no 5in the IETF LC comments of Feb 
12.This is a dramatically reduced version  that may be easier to accept 
atthis stage, still covering one of the missing functionalities in the 
draft.The asterisk is used as a preference parameter in the 
attributes.Thereby the proposed title change on 5.3With this additional 
  rule about where the asterisk(s) are placed, theanswering parties get 
good clues about the preferences betweenalternatives presented by the 
offeror. The chance to set up calls withsatisfied users increase 
dramatically compared to letting the answeringparty select by chance 
between alternatives.
- - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - -

A discussion about the meaning and use of this indication has occurred in:
https://www.ietf.org/mail-archive/web/slim/current/msg00803.html
Brian was concerned over wording questions from Randall introducing UI dependency in:
https://www.ietf.org/mail-archive/web/slim/current/msg00804.html
The current proposal has no wording about UI, it only in section 1 states the fact
that the parties need to become aware of the language negotiation outcome in order
  to be able to start the call in appropriate language(s) and modality(ies)
Arnoud has supported the need in:
https://www.ietf.org/mail-archive/web/slim/current/msg00809.html
***Status: Not resolved. *Randall has answered that he understands the intention and
use of this indication, but prefers to handle it in an additional draft. I still
claim that the current draft would need this function to meet urgent requirements.
*Further discussed i issue n) below.*




---------------------------------------------------------------------------------------------------

*f) 6. The cases in the "Silly states" section 5.4 are not all silly. *

Change the name of thesection to

"5.4 Unusual indications"
The section contains too weak specification about what to do with 
theunusual indications.
This is also noted by Bernard in:
https://www.ietf.org/mail-archive/web/slim/current/msg00728.html
"
  In particular, I would like the specification to describe:
a. What it means when a spoken language tag is included for a video stream.
Is this to be interpreted as a request for captioning?
b. What it means when a signed language tag is included for an audio stream.
Is the meaning of this "undefined" and if so, should it be ignored?
c. What it means when a signed language tag is included for a text stream.
If some of these scenarios are not defined, the specification can say
"this combination does not have a defined meaning" or something like that.

The discussion provided explanations of what all four unusual combinations
  mean, and considered that only the following were practical:
Spoken language in video media is an indication of a view of a speaker,
  when it is of importance for language perception.
Written language in video media is an indication of text captions embedded
  in video, either as integrated video overlay or as a text component in a
conglomerate coding declared as m=video.

A discussion took place under subject
"IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)",
noting that there is a problem to differentiate the indication of written language
in video and spoken language in video.
The use of the "Zxxx" Script subtag was discussed for indication of non-written
content (=spoken) language in video, or a script subtag for written language in video.
The use of these discriminating mechanisms were discouraged by Addison in:
https://www.ietf.org/mail-archive/web/slim/current/msg00757.html

Considering this resistance, we agreed to only keep the possibility to indicate
the view of the speaker in video of the four possible unusual cases. The others
  are documented as undefined.

But Bernard has an unanswered question in:
https://www.ietf.org/mail-archive/web/slim/current/msg00730.html

*"Assuming that we go that way, how would captioning be negotiated?"*

That is not solved for captioning by text overlay technologies in video, 
and I think we need to agree if we can ignore that usage.
Indicating captioning is also not solved in general, because it is a 
requirement for simultaneous use of languages in two media in contrast 
to all other indications that have mainly been about alternatives.
I return to that topic at the end of this summary.

*Status: Solved except that captions in video is left undefined and that 
decision needs to be confirmed,  and that indication of captions and 
other simultaneous use of language and media needs to be discussed**. *

  -----------------------------------------------------------------------------------------------------------
*g)  7. Examples section 5.5 requires expansion **
*
The examples section 5.5 was very brief, but got well extended in 
version -08.
However, Dale requested that it should contain an example of the request 
to see the speaker, in the 5.5 part of:
https://www.ietf.org/mail-archive/web/slim/current/msg00766.html

*Status: Good expansion of examples done, but example of request to see 
speaker is requested by the reviewer but not yet included.*


------------------------------------------------------------------------------------------------------------

*h). 8. Include more fields for attribute registration from 4566bis in 
section 6.***
*Status: Resolved exept that "Mux" is spelled "MUX" in version -08. The 
author has been provided a note about that.*

---------------------------------------------------------------------------------------------------------------


*i)     Should use of the expression "spoken/written language tag" be 
reworded?*
Addison discouraged from use of the expression "spoken/written language 
tag" in:

https://www.ietf.org/mail-archive/web/slim/current/msg00757.html

Yet, the expression appeared in section 5.4 of version -08.

*S**tatus: Addison should be consulted if the current use is acceptable, and 
if not, a rewording should be made.*

-----------------------------------------------------------------------------------------------------
*j.) The syntax of the attribute is questioned.*

Dale notes in the Gen-ART review nits section D of

https://www.ietf.org/mail-archive/web/slim/current/msg00766.html

That:
"D. Use the Accept-Language syntax
It seems to me that it would better to use the Accept-Language syntax
for the attribute values.  This allows (1) specifiying the quality of
language experience, allowing clear description of bilingualism, (2)
a unified method of specifying whether or not arbitrary languages are
acceptable, and (3) abbreviating SDP descriptions."

The syntax and semantics of the asterisk parameter is also questioned by Paul Kyziwat in:
https://www.ietf.org/mail-archive/web/slim/current/msg00758.html

Randall has answered in :
https://www.ietf.org/mail-archive/web/slim/current/msg00769.html
saying that the WG wanted to have asimple solution, not introducing q-values and other comlexities.


There has not been any further discussion on the proposal to use the 
Accept-Language syntax. It could solve both the neeed for preference 
indication to be valid between media and solve the need for indication 
of simultaneous use of language/media by just a little additional usage 
rule that the q-value has scope over the whole SDP, and that equal 
q-value for languages in the same direction means a request or 
capability to use these languages simultaneously ( e.g. needed to 
resolve the captioning issue ).

*Status: Using the Accept-Language syntax should be considered as a way 
to both clean up and shorten syntax, and a way to solve the need for 
indication of simultaneous use and of preference between language in 
different media.*
---------------------------------------------------------------------------------------------------
*k.) Shortening of the attribute names.*
Dale proposed shortening of the long attribute names and also 
introducing attributes for symmetric use of languages in both 
directions, in nits C and E of:
https://www.ietf.org/mail-archive/web/slim/current/msg00766.html
The shortening to "hlang-" was accepted, and is used in version -08.
The combination to bidirectional attributes was noted in answer on E in:
https://www.ietf.org/mail-archive/web/slim/current/msg00769.html

*Status: Partly accepted and implemented in version -08. No interest 
expressed to go further.*

------------------------------------------------------------------------------------------------------
*l). Call failure *
Dale proposed that the call failure should be more strictly specified  
in nits A of
https://www.ietf.org/mail-archive/web/slim/current/msg00766.html

This was accepted and after some discussion, the SIP returns and reason 
code and text was drafted and included in v - 08.

*Status: Done*
---------------------------------------------------------------------------------------------------------------------------
*m). New issues because of changed wording in version -07*

Version -07 was published on 2017-02-23.
It was found to have a number of mainly minor editorial issues 
summarised in:
https://www.ietf.org/mail-archive/web/slim/current/msg00786.html

They are all resolved in version -08, except the wider issue 12 that is 
identical to item e) above that is also summarised in issue n) below.

*Status: Resolved except issue 12 - handled under n) below.*

----------------------------------------------------------------------------------------------------------

*n). Indication of preference between media, and of simultanous versus 
alternative languages.*

This is a summary of the remaining issues related to items e), f), j) 
and m) above.

Issue e) proposes changes to enable indication of preference for 
language in different media.
Issue f) requests possibility to indicate request or offering of text 
captions of spoken language.
Issue j) proposes use of the Accept-Language syntax, that could both 
solve the functional needs
of e) and f) and sort out the syntax and semantics problems of the 
asterisk parameter.
Issue m) just indicates that issue e) is not yet resolved.

Randall has proposed to resolve the functional needs in a new draft, and 
not accept the Accept-Language syntax.
I have proposed a simple way to resolve issue e) - the preference 
between media, at the same time improving the definition of the 
semantics of the asterisk parameter.
No real solution to issue f) - the simultaneity indication  has been 
discussed.
Issue j) - the proposal to use the Accept-Language syntax can 
potentially be used to resolve issues e) and f).

  Discussion:
Issue e) says that there is a need to be able indicate which of a set of 
language/media indications are more preferred alternatives than others.
Examles are:
1. A want to get written English in text, A can as a less preferred 
alternative accept to get spoken English.  An answering party B who can 
will then respond with written text and get good satisfaction, while 
another answering user B without text capability will answer in spoken 
English and have a possibility for a reasonably successful call.
Without this indication, the first answering party may have answered 
with spoken English that will result in less satisfied users.
2. Prefer to receive text, and can accept to receive spoken language.   
When answering party can use text, that will be satisfied, otherwise 
soken language will be used.
3. Prefer to use spoken language in both directions, and can accept to 
use sign language in video in both directions. Answering party has a 
clear indication of why both spoken and written is indicated and can 
answer accordingly.
4. Prefer to use  sign language in both directions and can accept to use 
written language in both directions. Sign language users will use sign 
language, others will use text.
5. Prefer to send sign language and receive text (deaf-blind user), can 
accept to receive text.  In a call with a person with similar 
prefeences, text will be used both ways, otherwise sign one way and text 
the other.

etc.

Issue f) requires a way to indicate use of captioning and other 
situations where use of simultaneous languages in different modalities 
are needed:

1. Preference for hearing spoken language and simultaneously read 
written language in text. ( captioning) .   The time is approaching when 
this can be provided automatically, but also traditionally by a manned 
service.
2. Preference for hearing spoken language and simultaneously seeing the 
speaker in video.   (lip-reading).  Easily and naturally provided once 
the need i known.
3. Preference for seeing sign language and simultaneously hear spoken 
language in audio.  ( for multiple users at the terminal ) One of the 
streams is provided by an interpreter.
4. Preference for hearing spoken language and simultaneously view 
written language in video. (captioning if we accept to specify text as 
overlay on video)

Some of these can be acceptable also if just one of the language/media 
combinations can be provided, but is much more preferred if both can be 
provided together. In other cases it is essential to get both 
simultaneously. There is a need to differentiate in the indication that 
this preference for getting the languages together is preferred.

Alternative coding proposals:
1. Preference between language/modality
1.1 Based on draft -08, add the coding of an asterisk last in an 
attribute to mean lower preference for a lanugage/media combination than 
the one(s) without an asterisk.

1.2. Change to the Accept-Language syntax and let the q-values have 
scope over the whole SDP.

1.3. Introduce a new a=modality attribute on media level, with 
parameters: <modality>, <direction>, <preference>

2. Preference for simultaneous languages vs alternative languages:

2.1. Based on draft -08, add another notation to the use of the 
asterisk, e.g. an optional character to be used together with the 
asterisk to mark media that are wanted together. (ugly)

2.2. Use the Accept-Language syntax and add the usage rules that 
q-values with less than .1 difference mean languages with a preference 
to be used together. Higher differences indicate that they are 
alternatives.  Thereby it is both possible to indicate simultaneity and 
preference if the simultaneity cannot be satisfied.

2.3. Add to the new a=modality attribute a third, optional parameter 
[simultaneity]   with value any single letter, indicating a preference 
for having that modality simultaneously with another modality indicated 
with the same value in the [simultaneity] parameter.   Without this 
parameter, the modalities are alternatives.
*
**Status: Not solved. Conclusion needed on how to handle these issues e, 
f, and j,  both regarding which solution and what procedure to take to 
apply it.

*
-----------------------------------------------------------------------------------------------------------------------------------


*Summary: There are issues left to handle in items a, e, f, g, i, j and n.

*Regards

Gunnar
**
Den 2017-02-06 kl. 16:27, skrev The IESG:
> The IESG has received a request from the Selection of Language for
> Internet Media WG (slim) to consider the following document:
> - 'Negotiating Human Language in Real-Time Communications'
>    <draft-ietf-slim-negotiating-human-language-06.txt> as Proposed
> Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2017-02-20. Exceptionally, comments may be
> sent to [e-mail] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     Users have various human (natural) language needs, abilities, and
>     preferences regarding spoken, written, and signed languages.  When
>     establishing interactive communication ("calls") there needs to be a
>     way to negotiate (communicate and match) the caller's language and
>     media needs with the capabilities of the called party.  This is
>     especially important with emergency calls, where a call can be
>     handled by a call taker capable of communicating with the user, or a
>     translator or relay operator can be bridged into the call during
>     setup, but this applies to non-emergency calls as well (as an
>     example, when calling a company call center).
>
>     This document describes the need and a solution using new SDP stream
>     attributes.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>      draft-saintandre-sip-xmpp-chat: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat (None - )
> Note that some of these references may already be listed in the acceptable Downref Registry.
>
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]