Subject: [Slim] Open Issues on draft-ietf-slim-negotiating-human-language

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Apr 2017 11:25:18 -0700

Currently 10 Issues remain open from IETF Last Call:
https://trac.ietf.org/trac/slim/report/1

These include:
Ticket <https://trac.ietf.org/trac/slim/report/1?sort=ticket&asc=1&page=1>
Summary <https://trac.ietf.org/trac/slim/report/1?sort=summary&asc=1&page=1>
Component
<https://trac.ietf.org/trac/slim/report/1?sort=component&asc=1&page=1>
Version <https://trac.ietf.org/trac/slim/report/1?sort=version&asc=1&page=1>
Milestone
<https://trac.ietf.org/trac/slim/report/1?sort=milestone&asc=1&page=1>Type
<https://trac.ietf.org/trac/slim/report/1?sort=type&asc=1&page=1>Owner
<https://trac.ietf.org/trac/slim/report/1?sort=owner&asc=1&page=1>Status
<https://trac.ietf.org/trac/slim/report/1?sort=status&asc=1&page=1>Created
<https://trac.ietf.org/trac/slim/report/1?sort=created&asc=1&page=1>
#27 <https://trac.ietf.org/trac/slim/ticket/27> The cases in the "Silly
states" section 5.4 are not all silly.
<https://trac.ietf.org/trac/slim/ticket/27> negotiating-human-language 2.0
milestone1 <https://trac.ietf.org/trac/slim/milestone/milestone1> defect
[email-masked] new Mar 22, 2017
#19 <https://trac.ietf.org/trac/slim/ticket/19> Use Media Type registration
template <https://trac.ietf.org/trac/slim/ticket/19> multilangcontent
enhancement [email-masked] assigned Aug 17, 2016
#28 <https://trac.ietf.org/trac/slim/ticket/28> Examples section 5.5
requires expansion <https://trac.ietf.org/trac/slim/ticket/28>
negotiating-human-language 2.0 milestone1
<https://trac.ietf.org/trac/slim/milestone/milestone1> defect
[email-masked] assigned Mar 22, 2017
#32 <https://trac.ietf.org/trac/slim/ticket/32> Audio/Video Coordination
<https://trac.ietf.org/trac/slim/ticket/32> negotiating-human-language 2.0
milestone1 <https://trac.ietf.org/trac/slim/milestone/milestone1> defect
[email-masked] new Mar 22, 2017
#34 <https://trac.ietf.org/trac/slim/ticket/34> Use the Accept-Language
syntax <https://trac.ietf.org/trac/slim/ticket/34>
negotiating-human-language 2.0 milestone1
<https://trac.ietf.org/trac/slim/milestone/milestone1> defect
[email-masked] assigned Mar 22, 2017
#35 <https://trac.ietf.org/trac/slim/ticket/35> Have an attribute to
abbreviate the bidirectionally-symmetric case
<https://trac.ietf.org/trac/slim/ticket/35> negotiating-human-language 2.0
milestone1 <https://trac.ietf.org/trac/slim/milestone/milestone1> defect
[email-masked] assigned Mar 22, 2017
#38 <https://trac.ietf.org/trac/slim/ticket/38> Routing out of scope
<https://trac.ietf.org/trac/slim/ticket/38> negotiating-human-language 1.0
milestone1 <https://trac.ietf.org/trac/slim/milestone/milestone1> defect
[email-masked] new Apr 25, 2017
#39 <https://trac.ietf.org/trac/slim/ticket/39> Syntax Collapse
<https://trac.ietf.org/trac/slim/ticket/39> negotiating-human-language 1.0
milestone1 <https://trac.ietf.org/trac/slim/milestone/milestone1> defect
[email-masked] new Apr 25, 2017
#26 <https://trac.ietf.org/trac/slim/ticket/26> Make use of the asterisk
modifier on media level with session scope also for media level purposes
<https://trac.ietf.org/trac/slim/ticket/26> negotiating-human-language 2.0
milestone1 <https://trac.ietf.org/trac/slim/milestone/milestone1>
enhancement [email-masked] new Mar 22, 2017
#29 <https://trac.ietf.org/trac/slim/ticket/29> Include more fields for
attribute registration from 4566bis
<https://trac.ietf.org/trac/slim/ticket/29>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 26 Apr 2017 22:55:06 +0200

Bernard, thanks for the summary. We need decisions on these issues and 
move on.

How do you propose that decisions are taken?

A brief comment on #38 - routing: My memory of the discussion and 
decision is that we would not describe the routing logic and actions, 
but we should aim at producing indications that would have high 
likelihood to be usable for routing calls to appropriate call parties. 
Thus it needs to be possible to interrogate the indications by proxies 
even if TLS is used.

Regards

Gunnar

Den 2017-04-25 kl. 20:25, skrev Bernard Aboba:
> Ticket 
> <https://trac.ietf.org/trac/slim/report/1?sort=ticket&asc=1&page=1> 
> Summary 
> <https://trac.ietf.org/trac/slim/report/1?sort=summary&asc=1&page=1> 
> Component 
> 	Version 
> <https://trac.ietf.org/trac/slim/report/1?sort=version&asc=1&page=1> 
> Milestone 
> #27 <https://trac.ietf.org/trac/slim/ticket/27> 	The cases in the 
> "Silly states" section 5.4 are not all silly. 
> <https://trac.ietf.org/trac/slim/ticket/27> 
> [email-masked] <mailto:[email-masked]> 	new 
> Mar 22, 2017
> #19 <https://trac.ietf.org/trac/slim/ticket/19> 	Use Media Type 
> registration template <https://trac.ietf.org/trac/slim/ticket/19> 
> multilangcontent 	
> 	
> 	enhancement 	[email-masked] 
> <mailto:[email-masked]> 	assigned 	Aug 17, 2016
> [email-masked] <mailto:[email-masked]> 
> assigned 	Mar 22, 2017
> #32 <https://trac.ietf.org/trac/slim/ticket/32> 	Audio/Video 
> Coordination <https://trac.ietf.org/trac/slim/ticket/32> 
> [email-masked] <mailto:[email-masked]> 	new 
> Mar 22, 2017
> #34 <https://trac.ietf.org/trac/slim/ticket/34> 	Use the 
> Accept-Language syntax <https://trac.ietf.org/trac/slim/ticket/34> 
> [email-masked] <mailto:[email-masked]> 
> assigned 	Mar 22, 2017
> <https://trac.ietf.org/trac/slim/ticket/35> 
> [email-masked] <mailto:[email-masked]> 
> assigned 	Mar 22, 2017
> <https://trac.ietf.org/trac/slim/ticket/38> 
> negotiating-human-language 	1.0 	milestone1 
> [email-masked] 
> <mailto:[email-masked]> 	new 	Apr 
> 25, 2017
> <https://trac.ietf.org/trac/slim/ticket/39> 
> negotiating-human-language 	1.0 	milestone1 
> [email-masked] 
> <mailto:[email-masked]> 	new 	Apr 
> 25, 2017
> #26 <https://trac.ietf.org/trac/slim/ticket/26> 	Make use of the 
> asterisk modifier on media level with session scope also for media 
> level purposes <https://trac.ietf.org/trac/slim/ticket/26> 
> <https://trac.ietf.org/trac/slim/milestone/milestone1> 	enhancement 
> [email-masked] <mailto:[email-masked]> 	new 
> Mar 22, 2017
> #29 <https://trac.ietf.org/trac/slim/ticket/29> 	Include more fields 
> for attribute registration from 4566bis 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Apr 2017 16:15:12 -0500

> Thus it needs to be possible to interrogate the indications by proxies 

TLS is hop-by-hop in SIP (meaning it hides exactly nothing from 
proxies), so that's not an issue. The chances of S/MIME being broadly 
deployed in SIP do seem kind of slim, but thinking about what would 
happen if the body were encrypted is a good litmus test for "have I 
*really* messed up my layering?"

Given that the direction selected by the WG is to represent language 
values in SDP, I think this document can *either* say that routing is 
100% out of scope and unaddressed, *or* it can add some SIP-level header 
fields that bear on routing according to human languages. Anything that 
tries to split the difference is likely to cause architectural pain in 
the future, and an approach that I would counsel very strongly against.

/a

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Apr 2017 20:11:44 -0700

On Apr 26, 2017, at 14:15, Adam Roach <[email-masked]> wrote:
> 
> Given that the direction selected by the WG is to represent language values in SDP, I think this document can *either* say that routing is 100% out of scope and unaddressed, *or* it can add some SIP-level header fields that bear on routing according to human languages. 

[BA] Given that routing work is not in the current WG Charter, my suggestion would be for the current document to say it is out of scope. But it might also say that SIP-level header fields may be defined in future (if only to make it clear that the document is not suggesting SDP-based routing).

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 27 Apr 2017 11:22:58 +0200

> [BA] Given that routing work is not in the current WG Charter, my suggestion would be for the current document to say it is out of scope. But it might also say that SIP-level header fields may be d…
The charter is flexible about including routing aspects. It says:
"

  Alternatives such as doing the media
negotiation in SIP have been explored in the past and are out of scope
(although SIP-based mechanisms may be introduced when routing
considerations are addressed).

The group's initial focus will not be on supporting language-based call
routing decisions.  Once the initial work is sufficiently progressed, the
group may  address call routing, with the timing at the judgment of the
chairs.

"

I guess that  the work cannot be considered "sufficiently progressed" yet. So we should not deal with routing.
What we can do is to assume that an emergency service or call center application will put the call in an
appropriate queue just based on SIP fields, and the UAs that have language capabilities matching the indications
will answer.
However, I do not see how we can have a UA deciding if it has the best match among available UAs so that
it shall decide to answer the call.

Section 9.2 of RFC 6443 says: " To enable media-sensitive routing,
    the call should include a Session Description Protocol (SDP) offer
    [RFC3264 <https://tools.ietf.org/html/rfc3264>]."
So, there is an assumption that SDP can be interrogated to make routing decisions.

Can we just be silent about the routing aspects (as we are now) and assume that the
  media-sensitive routing mentioned in RFC 443 can be extended to "media and language based routing"?

Gunnar

-- ----------------------------------------- Gunnar Hellström Omnitor 
[email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 27 Apr 2017 17:19:17 +0200

The text in draft version -08 related to issue #27 has changed a lot 
since the version commented in LC.

It is currently:

"5.4.  Undefined Combinations

    With the exception of the case mentioned in Section 5.2 (a spoken
    language tag for a video stream in parallel with an audio stream with
    the same spoken language tag), the behavior when specifying a spoken/
    written language tag for a video media stream, or a signed language
    tag for an audio or text media stream, is not defined."

The referenced part of section 5.2 says:

"   Note that while signed language tags are used with a video stream to
    indicate sign language, a spoken language tag for a video stream in
    parallel with an audio stream with the same spoken language tag
    indicates a request for a supplemental video stream to see the
    speaker."

I think that is close to what we want. But we need to have decisions on 
if it is exactly what we want.

Points for decision:

1. Can we use the term "a spoken/written language tag" in 5.4? Addison 
Phillips did not like our use of that term in another paragraph, now 
reworded. I suggest to replace it with "a language tag used for a spoken 
or written language" and hope that is easier to accept.  However with my 
solution proposal for point 3 below, this problem disappears.

2. Are we satisfied with the solution that we cannot indicate use of 
text captions embedded in the video stream? It was long ago that I saw 
conversational products placing the text captions or text dialogue 
overlayed in the video stream. It is still in heavy use for streaming. 
So, if we do not believe that our specification will be used for 
streaming services, I think we are satisfied with the current 
limitation.  We had a proposal to always use the -Zxxx script subtag 
when we mean spoken modality, and usually no script subtag (or a 
specific script subtag when motivated for the languag when we mean a 
written modality, but there were some reluctance to that use of the 
-Zxxx script subtag for this purpose.
I suggest that we are happy with the current limitation, but want to 
hear others' views.

3. Are we satisfied with the limitation described in the section 5.2 
citation, requiring a spoken language tag used for the video stream to 
mean a view of a speaking person only if an audio stream has the same 
language tag assigned. I think that limitation is not needed and 
complicates the use.

Conclusion:

With my proposed resolutions on these points, we should change the two 
paragraphs cited above to:

"5.4.  Undefined Combinations

    The behavior when specifying a language tag for a written language for
    a video media stream, or a signed language tag for an audio or text 
media
    stream, is not defined."

The referenced part of section is then proposed to be:

"   Note that while signed language tags are used with a video stream to
    indicate sign language, a spoken language tag for a video stream
    indicates the view of a speaking person in the video stream."

If other than my proposals on the points are decided, the wording needs 
to be adjusted accordingly.

/Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 27 Apr 2017 22:52:33 +0200

When dealing with issue #28, making the examples more explicit, we 
should also deal with why the example with spoken two-way Spanish, 
Basque and English was understood as if pairing was supported in the 
message with subject "[Slim] [IANA #949701] expert review". It is not. I 
guess that the misunderstanding comes from the wording before the 
example saying in version -08 :

" An offer requesting spoken Spanish both ways (most preferred), spoken
    Basque both ways (second preference), or spoken English both ways
    (third preference).  The offer further requests that the call proceed
    even if the callee does not support any of the languages:

       m=audio 49250 RTP/AVP 20
       a=hlang-send:es*
       a=hlang-recv:es*
       a=hlang-send:eu*
       a=hlang-recv:eu*
       a=hlang-send:en*
       a=hlang-recv:en*
"

I assume that it is the language from the draft, using the terms "both 
ways ( x preference)" that causes an impression that the attributes are 
paired by the preference indications. In practice they will be, but 
there is nothing in our syntax that says that adjacent lines with 
different directions indicate pairing, and also nothing that says that 
indications on the same priority level are paired.

Maybe it will be more clear with the following rewording:

"An offer requesting sending of spoken Spanish , spoken
    Basque , or spoken English with preference in this order, and 
reception of spoken Spanish , spoken
    Basque , or spoken English also with preference in this order. The 
offer further requests that the call proceed
    even if the callee does not support any of the languages:"

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 27 Apr 2017 23:18:05 +0200

I noticed that the introduction of issue #32 introduces a definition of 
pairing.

Pairing is one of the two functions we lack and I have said that it 
needs to be added in the current draft or as an extension.

But exactly the kind of pairing discussed in issue #32 covers only the 
combination of speech and a view of the speaker by having exactly the 
same language tag in audio and video, and I just said in a comment to 
the related issue #27 that the complexity introduced by that pairing 
rule was too high and not needed.

If it had been a generally useful rule for pairing, I would gladly have 
accepted it.  But other cases of pairing that we eventually need to 
describe are e.g. a spoken language and a written language, for use as 
captions to the spoken language. Without pairing, they would be 
alternatives that can be used separately, and that can be the case even 
with exactly the same language tag for these two media.

Video and text would also be of interest to pair for getting text 
translations for sign language, or captions for speech.

So, I suggest that that part of #32 is not accepted, expecting a more 
general way of specifying pairing. ( that can be proposed when we have a 
solution for issue #39).

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 27 Apr 2017 23:31:35 +0200

I agree that the Accept-Language syntax is good with all language tags 
for one media and direction is collected in one attribute. Also 
including the q-value. I suggest that we go this way.

That would also satisfy issue #39.

The use of the q-values enable a simple definition of pairing and 
relative priority between languages in different media, saying that 
pairing is indicated by setting exactly the same q-value for two 
languages in the same direction but different media.

One required and one complementary language in different media but the 
same direction can be indicated by the q-values being less than 0.1 apart.

True alternatives in different media but the same direction can be 
indicated by th q-values being 0.1 or more apart.

That can be introduced i an extension or from the beginning.

/Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 27 Apr 2017 23:44:23 +0200

I exect that the abbreviation in issue #35 will be popular and support 
its addition.

However, all aspects of the indication must be equal in both directions 
to be used. So, when pairing and relative preference between modalities 
are introduced, either initially or as an extension, then this short 
form cannot be used for situations when pairing or relative preference 
is intended to be used in one direction or in different ways in 
different directions. And that is the most likely way of using pairing 
and relative preference between modalities.

Wording needs to be checked that it will allow and prepare for the 
extension.

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 27 Apr 2017 23:58:51 +0200

I agree that #26 is a sufficient method to add a relative preference 
between languages in different modalities. But it does not cover pairing 
that would e.g. be needed for captioning text to speech.

So, only if #34 can not be decided to be used with my proposed additions 
for pairing and relative preference, #26 should be accepted.

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 28 Apr 2017 12:07:18 +0200

Issue #26 started as a discussion of functionality extensions. That 
topic also relate to issues #34 and #39. Because the coding depends on 
the selection of resolution on these issues.

Bernard also brought up the need for coding of indications of captioning 
that is simultaneous use of languages in 
https://www.ietf.org/mail-archive/web/slim/current/msg00730.html. It 
could have been assigned a separate issue but I include discussion of 
that need here.

When resolving the current list of issues with 
draft-ietf-slim-negotiating-human-language we need to see how the two 
discussed functionlity extensions can be coded. The extensions are: a) 
relative preference between languages in different media and the same 
direction, and b) indication of simultaneous versus alternative use of 
languages in the same direction.

This is an overview of possible solutions to the functionality 
extensions and how they depend on the selected solutions of the issues. 
I have submitted similar proposals before, but this proposal is further 
limited to the two most suitable proposals. The earlier discussion 
containing more alternatives are found in 
https://mailarchive.ietf.org/arch/msg/slim/wR7iFD_gEINQh3RMGRFnj5kzGvA

The selected solutions for the functionality extensions can be included 
in the current draft or specified in a separate draft. If it is 
specified in a separate draft, the current draft needs to be checked and 
possibly adjusted so that it allows the selected syntax of the extensions.

*A. What we have specified in draft -08 is purely for lanuage  alternatives
*

The current specification is capable of negotiation of one language per 
media and direction. There is a way to express preference between 
languages within each media and direction, but no possibility to express 
preference between languages in the same direction in different media. 
There is freedom to use more than one media simultaneously if so decided 
but no indication if that is preferred.

*B. Indication of preference between media.*

There is a need to be able to indicate which of a set of language/media 
indications are more preferred alternatives than others.

Examples:

1. A user 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 use text will then respond with written text and get good 
satisfaction, while another answering user C without text capability 
will answer in spoken English and have a possibility for a reasonably 
successful call.
Without this indication, the first answering party B may have seen the 
spoken and written alternatives as true equal preference alternatives 
and answered with spoken English that will result in less satisfied users.

2. A user A prefer to receive spoken language, and can accept to receive 
text.   When answering party B can use spoken language, that will be 
satisfied, otherwise written language will be used.

3. A user A prefer to use spoken language in both directions, and can 
accept to use sign language in video in both directions. Answering party 
B has a clear indication of why both signed and written is indicated and 
can answer according to its capabilities trying to satisfy the 
preference for spoken language.

4. A user A 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. A user A prefer to send sign language and receive text (deaf-blind 
user) and can accept to send text.  In a call with a person with similar 
preferences, text will be used both ways, otherwise sign one way and 
text the other.

*Alternative coding proposals*

B.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.
example where audio and text are alternatives and text preferred
m=audio
a=hlang-recv:en*
m=text
a=hlang-recv:en

The asterisk is already specified to be used as an indication that the 
call should not be denied if language preferences cannot be met, but 
there is no rule for which attribute to put the asterisk for that 
purpose. This additional use of the asterisk brings a motivation to 
keeping the asterisk as a parameter on media level. There is slight, but 
manageable interaction between the two usages of the asterisk that needs 
to be expplained in the draft.

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

The Issue tracker issues #34 and #39 propose to change to a more 
condensed syntax. Both should be satisfied by using a syntax similar to 
the Accept-Language. If that route is taken, it opens for a quite clean 
way to add indication of relative preference between languages in 
different media.

Example where sign language is higher preferred than text.

  m=video 51372 RTP/AVP 31 32
  a=hlang-recv:ase;q=0.9
  a=hlang-send:ase;q=0.9

  m=text 49250 RTP/AVP 98,99
  a=hlang-send:en;q=0.5,*;q=0.1
  a=hlang-recv:en;q=0.5

Note that the asterisk is used here only with its original meaning as indication that the call
should not be denied if languages can not be matched.

*C. **Indication of simultanous versus alternative languages.*

A way is required to indicate use of captioning and other situations 
where use of simultaneous languages in different modalities are preferred:

1. Preference for hearing spoken language and simultaneously read 
written language in text. ( captioning) .   This can be provided 
automatically in some settings, but also traditionally by a manned 
service. The written language may be the same as the spoken, or another 
language.

2. Preference for hearing spoken language and simultaneously seeing the 
speaker in video.   (lip-reading).  Easily and naturally provided once 
the need is known.

3. Preference for seeing sign language and simultaneously hear spoken 
language in audio.  ( for multiple users at the terminal, or for hearing 
persons with some limited knowledge in the specified sign language )    
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 be able to indicate this preference 
for getting the languages together.

*Alternative coding proposals:*

C.1  Use the -t- subtag for transformed content on a language indication 
defined in RFC 6497 as an indication that this language can be provided 
or is desired together with a language in another modality. Use this 
indication together with solution B.1

Example: Indicate that written English and spoken English are desired 
together and written English expected to be transformed.  but the call 
shall not be denied if that combination is not possible, and then 
written English is preferred.

m=text
a=hlang-recv:en-t-en
m=audio
a=hlang-recv:en*

The -t- indicated with the -recv direction shall not be understood that 
the indicated language needs to be transformed. It is just an 
expectation that enables it to express that the languages should be 
provided simultaneously.

C.2. Use the Accept-Language syntax for the hlang attributes 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.

  m=audio 51372 RTP/AVP 0
  a=hlang-recv:ase;q=0.5
  a=hlang-send:ase;q=0.5

  m=text 49250 RTP/AVP 98,99
  a=hlang-send:en;q=0.51
  a=hlang-recv:en;q=0.51,*;q=0.1

The q-values differences are within 0.1 so it indicates a preference for getting both together,
but if that is not possible, text is preferred.

*Judgement of the alternatives:*
I have a preference for solutions B.2 and C.2 because they are logically 
most clean. They require that we accept the proposals in Issues #34 and 
#39 to move to the Accept-Language syntax.

B.1 and C.1 are easily added to the syntax of the current draft and have 
sufficient functionality for most cases. There will be some limitations. 
B.1 helps to motivate to keep the * parameter on media level. The use of 
the -t-  language subtag in B.2 may need discussion with language coding 
experts.

Summary:  I suggest to accept the proposal in #34, and use the coding 
B.2 and C.2 above for the functionality extensions. That would mean that 
the use of the asterisk is only for non-denial indication.

Gunnar