Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt

From: [email-masked]
Date: Wed, 22 Feb 2017 20:06:36 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Selection of Language for Internet Media of the IETF.

        Title           : Negotiating Human Language in Real-Time Communications
        Author          : Randall Gellens
	Filename        : draft-ietf-slim-negotiating-human-language-07.txt
	Pages           : 17
	Date            : 2017-02-22

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 media
   attributes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Randall Gellens <[email-masked]>
Date: Wed, 22 Feb 2017 20:15:58 -0800

Version -07 addresses all comments except for the unresolved issue of 
renaming the two attributes which is currently being discussed on the 
list, and adding a new attribute for bidirectionality.

Per Dale's suggestion, the draft adds advice that if a call is 
rejected due to no languages in common, SIP response code 488 (Not 
Acceptable Here) or 606 (Not Acceptable) be used, along with a 
Warning header field indicating the supported languages.  The draft 
registers a new entry in the warn-code sub-registry of SIP parameters 
for this purpose.  The draft also has an expanded set of examples.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Ninety percent of the politicians give the other ten percent a bad name.
                                                      --Henry Kissinger

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 24 Feb 2017 17:35:00 +0100

Den 2017-02-23 kl. 05:15, skrev Randall Gellens:
> Acceptable Here) or 606 (Not Acceptable) be used, along with a Warning 
> header field indicating the supported languages.  The draft registers 
> a new entry in the warn-code sub-registry of SIP parameters for this 
> purpose.  The draft also has an expanded set of examples.
>
Good progress. Good to see the enriched examples chapter 5.5.
I have a few comments on version -07:

1.  Section  4. second line
------------old text----------------------
but is not sufficiently sufficiently
------------new text--------------------------
but is not sufficiently
----------end of change 1-----------------
Motivation: New typo in version -07

2. Section 5.2, first line
----------------old text-----------------
This document defines two new media-level ..
----------------new text----------------------
This document defines two media-level ...
----------------end of change 2----------------
Motivation: It was commented that when the draft is published, this is 
not new anymore.
There are three more occasions of "new" in the document that may be 
modified as well.

3.  5.2 second paragraph
-------------------old text--------------------------------
In an offer, the 'humintlang-send' values indicates the language(s)
    the offerer is willing to use when sending using the media, and the
    'humintlang-recv' values indicates the language(s) the offerer is
    willing to use when receiving using the media.
-----------------new text---------------------------------
In an offer, the 'humintlang-send' values indicate the language(s)
the offerer is willing to select from for use when sending using the
media, and the 'humintlang-recv' values indicate the language(s) the
offerer is willing to receive one of in the media stream.
----------------end of change----------------------------------
Motivation 1:) change from "indicates" to "indicate" in two places to 
match the new use of plural "values".
Motivation 2:) Be sure to indicate that we only intend to negotiate one 
language per media and direction, so that we do not end up as 
unspecified regarding number of matches required as the sdp "lang" 
attribute is.

4.  5.2 Second paragraph
-----------------old text-----------------------
When a media is intended
    for use in one direction only
----------------new text---------------------
When a media is intended
    for use for language communication in one direction only
----------------end of change---------------------------
Motivation: Deletion of a note in this sentence made it less obvious 
that we are only talking about directions of use of language 
communication, and not about establishing asymmetric media connections. 
Therefore add this clarification.

5.  5.2 Deleted paragraph 6 before "Clients acting on behalf..."
----------reinsert modified paragraph----------------------------
While signed language tags are used with a video stream to
indicate sign language, a spoken language tag for a video stream
indicates a request or offer to see the speaker, when that is of
importance for language perception.
-------------end of change-------------------------------------------
Motivation: There was in the LC mail exchange a discussion about 
sharpening up the specification of use of "unusual combinations".
There was no agreement to delete them all. The one described in this 
paragraph is the main one that has widespread use and needs to be 
clearly specified for use by a large number of hard-of-hearing and deaf 
users.

6.  5.2 Sixth paragraph
--------------------current text--------------------
(or for unidirectional streams, one of)
------------------new text ------------------------
(or for asymmetrical use of languages, one of)
-----------------end of change----------------------
Motivation: We are not primarily talking about enabled transmission 
directions of the streams, but about language use in the streams. We do 
not want to limit the media stream directions just because we do not 
specify an initial language to use for that direction. There are other 
usage of media, and there may even be occasional use of language in the 
direction, just not worth mentioning as an initial and preferred use. 
The suggested change should make that clear.

7.   5.3 Next to last paragraph
------------------old text------------------------------
a list of supported languages.
-------------------new text-------------------------
a list of supported languages, media and directions.
-------------------end of change----------------
Motivation: It is not sufficient to know which languages are supported, 
it is also essential to know in which media they are supported and in 
which directions. (media could be replaced with modality, but the media 
can become ambigous then, so use media here to be brief.

8.      5.3, last line
--------------old text----------------------------------
  Supported languages are: es, en"
--------------new text-------------------------------
  Supported languages are: es, en transmission in audio; es, en 
reception in audio"
----------------------------------------------------------
Motivation: Same as for 7.

9.  5.4 Undefined combinations
----------------------------old text--------------------------------------
    The behavior when specifying a non-signed language tag for a video
    media stream, or a signed language tag for an audio or text media
    stream, is not defined.
---------------------------new text-----------------------------------------
There is no way specified for indicating use of text based language in a 
video media stream.
There is no meaning assigned to specification of  sign language in an 
audio or text media stream.
--------------------------end of change-------------------------------
Motivation: Seeing the speaker in video is an important combination 
reinserted above in section 5.2.
This section therefore needed rewording to not include that combination.

10.     6.2 Last sentence
-----------------current text---------------------
Supported languages are: [list of supported languages]."
-----------------new text------------------------
Supported languages and media and transmission directions are:[list of 
supported languages and media and transmission directions.]"
-----------------end of change--------------------------
Motivation: Same as for 7.

11.  6.1 MUX Category
----------old text in two locations-------------------
MUX Category:  normal
---------new text in same two locations--------------
Mux Category:  NORMAL
---------end of change-----------------
Motivation: Follow RFC 4566bis and IANA habits regarding use of capitals

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, second 
paragraph-------------------------------
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 fail 
the 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 in 
5.3--------------------------------------
Motivation: There has not yet been any conclusion for my proposal no 5 
in the IETF LC comments of Feb 12.
This is a dramatically reduced version that may be easier to accept at 
this 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.3
With this additional rule about where the asterisk(s) are placed, the 
answering parties get good clues about the preferences between 
alternatives presented by the offeror. The chance to set up calls with 
satisfied users increase dramatically compared to letting the answering 
party select by chance between alternatives.

Regards

Gunnar

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

---

From: Randall Gellens <[email-masked]>
Date: Fri, 24 Feb 2017 16:32:55 -0800

At 5:35 PM +0100 2/24/17, Gunnar Hellström wrote:

>>  Version -07 addresses all comments except for 
>> the unresolved issue of renaming the two 
>> attributes which is currently being discussed 
>> on the list, and adding a new attribute for 
>> bidirectionality.
>>
>>  Per Dale's suggestion, the draft adds advice 
>> that if a call is rejected due to no languages 
>> in common, SIP response code 488 (Not 
>> Acceptable Here) or 606 (Not Acceptable) be 
>> used, along with a Warning header field 
>> indicating the supported languages.  The draft 
>> registers a new entry in the warn-code 
>> sub-registry of SIP parameters for this 

Thanks.

>  Motivation: It was commented that when the 
> draft is published, this is not new anymore.
>  There are three more occasions of "new" in the 
> document that may be modified as well.

OK.

>  Motivation 1:) change from "indicates" to 
> "indicate" in two places to match the new use 
> of plural "values".
>  Motivation 2:) Be sure to indicate that we only 
> intend to negotiate one language per media and 
> direction, so that we do not end up as 
> unspecified regarding number of matches 
> required as the sdp "lang" attribute is.

Reworded.

>  Motivation: Deletion of a note in this sentence 
> made it less obvious that we are only talking 
> about directions of use of language 
> communication, and not about establishing 
> asymmetric media connections. Therefore add 
> this clarification.

Reworded.

>  Motivation: There was in the LC mail exchange a 
> discussion about sharpening up the 
> specification of use of "unusual combinations".
>  There was no agreement to delete them all. The 
> one described in this paragraph is the main one 
> that has widespread use and needs to be clearly 
> specified for use by a large number of 
> hard-of-hearing and deaf users.

The text as it is now does not prohibit anything 
and explicitly mentions negotiating supplemental 
video by omitting language attributes on a video 
media.

>  Motivation: We are not primarily talking about 
> enabled transmission directions of the streams, 
> but about language use in the streams. We do 
> not want to limit the media stream directions 
> just because we do not specify an initial 
> language to use for that direction. There are 
> other usage of media, and there may even be 
> occasional use of language in the direction, 
> just not worth mentioning as an initial and 
> preferred use. The suggested change should make 
> that clear.
>
>  Motivation: It is not sufficient to know which 
> languages are supported, it is also essential 
> to know in which media they are supported and 
> in which directions. (media could be replaced 
> with modality, but the media can become 
> ambigous then, so use media here to be brief.

I don't know that we can require this, but I'll 
add SHOULD kist supported languages and media. 
Demanding direction as well might be too unwieldy.

>   Supported languages are: es, en transmission 
> in audio; es, en reception in audio"

Fixed as above.

>  There is no way specified for indicating use of 
> text based language in a video media stream.
>  There is no meaning assigned to specification 
> of  sign language in an audio or text media 
> stream.
>  Motivation: Seeing the speaker in video is an 
> important combination reinserted above in 
> section 5.2.

The draft explicitly mentions video for supplemental purposes.

>  Supported languages and media and transmission 
> directions are:[list of supported languages and 
> media and transmission directions.]"

Fixed as above.

>  Motivation: Follow RFC 4566bis and IANA habits regarding use of capitals

Fixed.

>  ------------end of change 1 in 5.3---------------

The section is more than just the asterisk, it 
also advises use of specific SIP response codes 
if the call is failed.

>
>  -------------old text-in 5.3, second paragraph-------------------------------
>  Motivation: There has not yet been any 
> conclusion for my proposal no 5 in the IETF LC 
> comments of Feb 12.
>  This is a dramatically reduced version that may 
> be easier to accept at this 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.3
>  With this additional rule about where the 
> asterisk(s) are placed, the answering parties 
> get good clues about the preferences between 
> alternatives presented by the offeror. The 
> chance to set up calls with satisfied users 
> increase dramatically compared to letting the 
> answering party select by chance between 
> alternatives.

Making the asterisk a purely-advisory hint as to 
the least-preferred media/language combination 
seems harmless enough, as it would not be 
required to support it; however, I'm not sure it 
provides any benefit: if an offer contains some 
set of media with language, and the answerer can 
support all of them, should the answerer only 
include in its answer those without an asterisk? 
It seems simpler for the answerer to include 
everything in the offer that it can support.

-------------- Randomly selected tag: ---------------
The great Chinese philosopher Confucius wrote, "When words lose their
meaning, the universe crumbles."  Theologically and cosmologically, I'm
not sure about that.  I am sure that when our government is
characterized as "amoral, godless and secularist," our public schools
as "failures" and our judges as "tyrants," simplistic solutions
promoted by demagogues will seem appropriate.
-- Barry Lynn,
   Executive Director of
   Americans United for Separation of Church and State

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 25 Feb 2017 11:04:53 +0100

Randall,

Fine, I find that we have only issues 5, 6 and 12 still to discuss.

You did not answer issue 6, use of asymmetrical language rather than 
unidirectional media. I assume you accepted it.

On 5, the request to reinsert wording about seeing the speaker in video, 
it is still a huge difference in specifying a preference to see the 
speaker for language perception reasons, versus only specifying that I 
want a video stream for supplementary purposes. With the current wording 
in version -07, section 5.3 says that that combination is undefined. 
Nothing in the LC discussion indicated that it should be undefined. Why 
did you suddenly want to delete it? It is useful. Please reinsert with 
the wording changes I propose.

On 12, the meaning of the placement of the asterisk, you ask:
"Making the asterisk a purely-advisory hint as to the least-preferred 
media/language combination seems harmless enough, as it would not be 
required to support it; however, I'm not sure it provides any benefit: 
if an offer contains some set of media with language, and the answerer 
can support all of them, should the answerer only include in its answer 
those without an asterisk? It seems simpler for the answerer to include 
everything in the offer that it can support."

The answering party should aim at answering with one of the languages 
that is without the asterisk in the offer. Only if the answering party 
does not have capability in a language without an asterisk, one with 
asterisk should be selected. Thereby you get the best opportunity to 
start the call in a language combination that satisfies both users.

Example: A hard-of-hearing user can just barely conduct spoken calls 
with persons she knows. From others it is much more reliable to get 
text.  She calls and declares:

m=audio
a=huml-send:en
a=huml-recv:en*
m=text
a=huml-recv:en

The answering party with text capabilities sees that matching text for 
sending is higher preferred than talking, and thus  responds:

m=audio
a=huml-recv:en
m=text
a=huml-send:en

The answering party sends the initial greeting in text and the call 
continues smoothly in well managed langauage/modality combinations.

Another called party may not have text capabilities, and may therefore 
select the less favoured alternative with using speech both ways, answering:

m=audio
a=huml-recv:en
a=huml-send:en
m=text 0

The answering party starts taking and the parties try as well as 
possible to manage the call in this less preferred combination that may 
be less reliable.

If the placement of the asterisk had no special meaning as it is in 
version -07, it is a high risk that the answering party in the first 
example would select to answer with spoken language that would be 
unreliably received. Time and effort would be spent by speech to make 
the answering party switch to sending text instead of talking in order 
to arrange for a more reliable call situation.

If instead the caller only indicated the most favoured combinations,

m=audio
a=huml-send:en
m=text
a=huml-recv:en

Then the answering parties without text capability would not dare to try 
to answer, and a reasonably successful call would be missed.

Many other similar realistic examples can be created, where placement of 
the asterisk(s) would be a sufficient indication of lower preference for 
language match among alternatives that would make call establishment 
successful and smooth in many more cases than without this indication 
opportunity.

Do you want more examples?

Please accept proposal 12.

Regards

Gunnar

Den 2017-02-25 kl. 01:32, skrev Randall Gellens:
>>>  Version -07 addresses all comments except for the unresolved issue 
>>> of renaming the two attributes which is currently being discussed on 
>>> the list, and adding a new attribute for bidirectionality.
>>>
>>> registers a new entry in the warn-code sub-registry of SIP 
>>> parameters for this purpose.  The draft also has an expanded set of 
>>> examples.
>>>
>>  Motivation: It was commented that when the draft is published, this 
>> is not new anymore.
>>  Motivation 1:) change from "indicates" to "indicate" in two places 
>> to match the new use of plural "values".
>>  Motivation 2:) Be sure to indicate that we only intend to negotiate 
>> one language per media and direction, so that we do not end up as 
>> communication, and not about establishing asymmetric media 
>> connections. Therefore add this clarification.
>
> Reworded.
>
>>
>> clearly specified for use by a large number of hard-of-hearing and 
>> deaf users.
>
> The text as it is now does not prohibit anything and explicitly 
> mentions negotiating supplemental video by omitting language 
> attributes on a video media.
>
>>
>>  6.  5.2 Sixth paragraph
>> directions of the streams, but about language use in the streams. We 
>> do not want to limit the media stream directions just because we do 
>> not specify an initial language to use for that direction. There are 
>> other usage of media, and there may even be occasional use of 
>> language in the direction, just not worth mentioning as an initial 
>> and preferred use. The suggested change should make that clear.
>>
>>  Motivation: It is not sufficient to know which languages are 
>> supported, it is also essential to know in which media they are 
>> supported and in which directions. (media could be replaced with 
>> modality, but the media can become ambigous then, so use media here 
>> to be brief.
>
> I don't know that we can require this, but I'll add SHOULD kist 
> supported languages and media. Demanding direction as well might be 
> too unwieldy.
>
>>
>>  8.      5.3, last line
>>  ----------------------------old 
>> text--------------------------------------
>>  ---------------------------new 
>> text-----------------------------------------
>>  There is no way specified for indicating use of text based language 
>> in a video media stream.
>>  There is no meaning assigned to specification of  sign language in 
>> an audio or text media stream.
>>  Supported languages and media and transmission directions are:[list 
>> of supported languages and media and transmission directions.]"
> The section is more than just the asterisk, it also advises use of 
> specific SIP response codes if the call is failed.
>
>
>>
>>  Motivation: There has not yet been any conclusion for my proposal no 
>> 5 in the IETF LC comments of Feb 12.
>>  This is a dramatically reduced version that may be easier to accept 
>> at this stage, still covering one of the missing functionalities in 
>> the draft.
>>  With this additional rule about where the asterisk(s) are placed, 
>> the answering parties get good clues about the preferences between 
>> alternatives presented by the offeror. The chance to set up calls 
>> with satisfied users increase dramatically compared to letting the 
>> answering party select by chance between alternatives.
>
> Making the asterisk a purely-advisory hint as to the least-preferred 
> media/language combination seems harmless enough, as it would not be 
> required to support it; however, I'm not sure it provides any benefit: 
> if an offer contains some set of media with language, and the answerer 
> can support all of them, should the answerer only include in its 
> answer those without an asterisk? It seems simpler for the answerer to 
> include everything in the offer that it can support.
>
>

---

From: Randall Gellens <[email-masked]>
Date: Sat, 25 Feb 2017 11:58:17 -0800

Hi Gunnar,

At 11:04 AM +0100 2/25/17, Gunnar Hellström wrote:

>  You did not answer issue 6, use of asymmetrical 
> language rather than unidirectional media. I 
> assume you accepted it.

Yes, I thought I had indicated that, sorry if I didn't.

>
>  On 5, the request to reinsert wording about 
> seeing the speaker in video, it is still a huge 
> difference in specifying a preference to see 
> the speaker for language perception reasons, 
> versus only specifying that I want a video 
> stream for supplementary purposes. With the 
> current wording in version -07, section 5.3 
> says that that combination is undefined. 
> Nothing in the LC discussion indicated that it 
> should be undefined. Why did you suddenly want 
> to delete it? It is useful. Please reinsert 
> with the wording changes I propose.

The email discussion led me to believe that the 
text was controversial.  We need to get the draft 
finished, so it's better to delete controversial 
text than to spend months fighting about it.

>  "Making the asterisk a purely-advisory hint as 
> to the least-preferred media/language 
> combination seems harmless enough, as it would 
> not be required to support it; however, I'm not 
> sure it provides any benefit: if an offer 
> contains some set of media with language, and 
> the answerer can support all of them, should 
> the answerer only include in its answer those 
> without an asterisk? It seems simpler for the 
> answerer to include everything in the offer 
> that it can support."
>
>  The answering party should aim at answering 
> with one of the languages that is without the 
> asterisk in the offer. Only if the answering 
> party does not have capability in a language 
> without an asterisk, one with asterisk should 
> be selected. Thereby you get the best 
> opportunity to start the call in a language 
> combination that satisfies both users.
>
>  Example: A hard-of-hearing user can just barely 
> conduct spoken calls with persons she knows. 
> From others it is much more reliable to get 
>  The answering party with text capabilities sees 
> that matching text for sending is higher 
> preferred than talking, and thus  responds:
>
>  m=audio
>  a=huml-recv:en
>  m=text
>  a=huml-send:en
>
>  The answering party sends the initial greeting 
> in text and the call continues smoothly in well 
> managed langauage/modality combinations.
>
>  Another called party may not have text 
> capabilities, and may therefore select the less 
> favoured alternative with using speech both 
> ways, answering:
>
>  m=audio
>  a=huml-recv:en
>  a=huml-send:en
>  m=text 0
>
>  The answering party starts taking and the 
> parties try as well as possible to manage the 
> call in this less preferred combination that 
> may be less reliable.
>
>  If the placement of the asterisk had no special 
> meaning as it is in version -07, it is a high 
> risk that the answering party in the first 
> example would select to answer with spoken 
> language that would be unreliably received. 
> Time and effort would be spent by speech to 
> make the answering party switch to sending text 
> instead of talking in order to arrange for a 
> more reliable call situation.
>
>  Then the answering parties without text 
> capability would not dare to try to answer, and 
> a reasonably successful call would be missed.
>
>  Many other similar realistic examples can be 
> created, where placement of the asterisk(s) 
> would be a sufficient indication of lower 
> preference for language match among 
> alternatives that would make call establishment 
> successful and smooth in many more cases than 
> without this indication opportunity.
>

This convinces me that we cannot accept the 
proposed text, as it would introduce complexity 
that the WG explicitly decided to not pursue in 
this draft.  In the examples you provided, it 
seems better for the answerer to include all 
media and languages from the offer that it can 
support.  This is much simpler, has only trivial 
drawbacks (extra media negotiated that might not 
be used), and is what the WG agreed to.

--Randy

>>>>   Version -07 addresses all comments except 
>>>> for the unresolved issue of renaming the two 
>>>> attributes which is currently being 
>>>> discussed on the list, and adding a new 
>>>> attribute for bidirectionality.
>>>>
>>>>   Per Dale's suggestion, the draft adds 
>>>> advice that if a call is rejected due to no 
>>>> languages in common, SIP response code 488 
>>>> (Not Acceptable Here) or 606 (Not 
>>>> Acceptable) be used, along with a Warning 
>>>> header field indicating the supported 
>>>> languages.  The draft registers a new entry 
>>>> in the warn-code sub-registry of SIP 
>>>> parameters for this purpose.  The draft also 
>>>> has an expanded set of examples.
>>>>
>>>   There are three more occasions of "new" in 
>>> the document that may be modified as well.
>>
>>  OK.
>>
>>>
>>>   3.  5.2 second paragraph
>>>   Motivation 2:) Be sure to indicate that we 
>>> only intend to negotiate one language per 
>>> media and direction, so that we do not end up 
>>> as unspecified regarding number of matches 
>>>   Motivation: Deletion of a note in this 
>>> sentence made it less obvious that we are 
>>> only talking about directions of use of 
>>> language communication, and not about 
>>> establishing asymmetric media connections. 
>>>   Motivation: There was in the LC mail 
>>> exchange a discussion about sharpening up the 
>>>   There was no agreement to delete them all. 
>>> The one described in this paragraph is the 
>>> main one that has widespread use and needs to 
>>> be clearly specified for use by a large 
>>> number of hard-of-hearing and deaf users.
>>
>>  The text as it is now does not prohibit 
>> anything and explicitly mentions negotiating 
>> supplemental video by omitting language 
>>>   Motivation: We are not primarily talking 
>>> about enabled transmission directions of the 
>>> streams, but about language use in the 
>>> streams. We do not want to limit the media 
>>> stream directions just because we do not 
>>> specify an initial language to use for that 
>>> direction. There are other usage of media, 
>>> and there may even be occasional use of 
>>> language in the direction, just not worth 
>>> mentioning as an initial and preferred use. 
>>>   Motivation: It is not sufficient to know 
>>> which languages are supported, it is also 
>>> essential to know in which media they are 
>>> supported and in which directions. (media 
>>> could be replaced with modality, but the 
>>> media can become ambigous then, so use media 
>>> here to be brief.
>>
>>  I don't know that we can require this, but 
>> I'll add SHOULD kist supported languages and 
>> media. Demanding direction as well might be 
>> too unwieldy.
>>
>>>
>>>   8.      5.3, last line
>>>    Supported languages are: es, en 
>>> transmission in audio; es, en reception in 
>>> audio"
>>>   There is no way specified for indicating use 
>>> of text based language in a video media 
>>> stream.
>>>   There is no meaning assigned to 
>>> specification of  sign language in an audio 
>>> or text media stream.
>>>   Motivation: Seeing the speaker in video is 
>>> an important combination reinserted above in 
>>> section 5.2.
>> also advises use of specific SIP response 
>> codes if the call is failed.
>>
>>>
>>>      send' values is an asterisk, this 
>>> indicates a request to not fail the call.
>>>   ---------------------------end of change 2 
>>> in 5.3--------------------------------------
>>> conclusion for my proposal no 5 in the IETF 
>>> LC comments of Feb 12.
>>>   This is a dramatically reduced version that 
>>> may be easier to accept at this 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.3
>>  Making the asterisk a purely-advisory hint as 
>> to the least-preferred media/language 
>> combination seems harmless enough, as it would 
>> not be required to support it; however, I'm 
>> not sure it provides any benefit: if an offer 
>> contains some set of media with language, and 
>> the answerer can support all of them, should 
>> the answerer only include in its answer those 
>> without an asterisk? It seems simpler for the 
>> answerer to include everything in the offer 
>> that it can support.
>>
>
>  --

-------------- Randomly selected tag: ---------------
(If you can't hear me, it's because I'm in parentheses)

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 26 Feb 2017 07:46:01 +0100

> Yes, I thought I had indicated that, sorry if I didn't.
Good.
>
>>
>>  On 5, the request to reinsert wording about seeing the speaker in 
>> video, it is still a huge difference in specifying a preference to 
>> see the speaker for language perception reasons, versus only 
>> specifying that I want a video stream for supplementary purposes. 
>> With the current wording in version -07, section 5.3 says that that 
>> combination is undefined. Nothing in the LC discussion indicated that 
>> it should be undefined. Why did you suddenly want to delete it? It is 
>> useful. Please reinsert with the wording changes I propose.
>
> The email discussion led me to believe that the text was 
> controversial.  We need to get the draft finished, so it's better to 
> delete controversial text than to spend months fighting about it.
The comments were first about the uncertainty about how the "silly 
states" were to be interpreted.
We described them all but decided to only keep the view of the speaker 
because it is a real and useful case.
The idea to differentiate spoken and written cases by script tags caused 
discussions and was dropped. The remaining real case with the view of 
the speaker was mentioned twice in the draft, so it was recommended that 
one of them should be deleted, but not both.
>>  "Making the asterisk a purely-advisory hint as to the 
>> least-preferred media/language combination seems harmless enough, as 
>> it would not be required to support it; however, I'm not sure it 
>> provides any benefit: if an offer contains some set of media with 
>> language, and the answerer can support all of them, should the 
>> answerer only include in its answer those without an asterisk? It 
>> seems simpler for the answerer to include everything in the offer 
>> that it can support."
>>
>>  The answering party should aim at answering with one of the 
>> languages that is without the asterisk in the offer. Only if the 
>> answering party does not have capability in a language without an 
>> asterisk, one with asterisk should be selected. Thereby you get the 
>> best opportunity to start the call in a language combination that 
>> satisfies both users.
>>
>>  The answering party with text capabilities sees that matching text 
>> for sending is higher preferred than talking, and thus responds:
>>
>>  m=audio
>>  a=huml-recv:en
>>  m=text
>>  a=huml-send:en
>>
>>  Another called party may not have text capabilities, and may 
>> therefore select the less favoured alternative with using speech both 
>> ways, answering:
>>
>>  m=audio
>>  a=huml-recv:en
>>  a=huml-send:en
>>  m=text 0
>>
>> possible to manage the call in this less preferred combination that 
>> may be less reliable.
>>
>> the answering party switch to sending text instead of talking in 
>> order to arrange for a more reliable call situation.
>>
>>  Then the answering parties without text capability would not dare to 
>> try to answer, and a reasonably successful call would be missed.
>>
>>  Many other similar realistic examples can be created, where 
>> placement of the asterisk(s) would be a sufficient indication of 
>> lower preference for language match among alternatives that would 
>> make call establishment successful and smooth in many more cases than 
> This convinces me that we cannot accept the proposed text, as it would 
> introduce complexity that the WG explicitly decided to not pursue in 
> this draft.  In the examples you provided, it seems better for the 
> answerer to include all media and languages from the offer that it can 
> support.  This is much simpler, has only trivial drawbacks (extra 
> media negotiated that might not be used), and is what the WG agreed to.
Yes, you could let the answer SDP contain one common language per media 
and direction, but the answering human need guidance on which language 
is best suited to start the conversation. Therefore the placement of the 
asterisk is used to hint the answering party how to start the call.

The first example above can be modified to:

  m=audio
  a=huml-send:en
  a=huml-recv:en*
  m=text
  a=huml-recv:en

  The answering party with capabilities for both written and spoken 
English sees that matching text for sending is higher preferred than 
talking and sends the answer indicating the capabilities:

  m=audio
  a=huml-recv:en
a=huml-send:en
  m=text
  a=huml-send:en

  The answering party makes use of the hint that the caller prefers to 
receive written text and therefore sends the initial greeting in text 
and the call continues smoothly in well managed langauage/modality 
combinations.

----------
There is no complexity left in this solution, it helps to motivate why 
we have the asterisk on media level, and it helps to successful call 
initiations, so I think it should be acceptable.

Gunnar

>>>>>   Version -07 addresses all comments except for the unresolved 
>>>>> issue of renaming the two attributes which is currently being 
>>>>> discussed on the list, and adding a new attribute for 
>>>>> bidirectionality.
>>>>>
>>>>> Warning header field indicating the supported languages.  The 
>>>>> draft registers a new entry in the warn-code sub-registry of SIP 
>>>>> parameters for this purpose.  The draft also has an expanded set 
>>>>> of examples.
>>>>>
>>>>   Motivation: It was commented that when the draft is published, 
>>>> this is not new anymore.
>>>>   There are three more occasions of "new" in the document that may 
>>>> be modified as well.
>>>
>>>  OK.
>>>
>>>>
>>>>   3.  5.2 second paragraph
>>>>   Motivation 1:) change from "indicates" to "indicate" in two 
>>>> places to match the new use of plural "values".
>>>>   Motivation 2:) Be sure to indicate that we only intend to 
>>>> negotiate one language per media and direction, so that we do not 
>>>> end up as unspecified regarding number of matches required as the 
>>>> sdp "lang" attribute is.
>>>
>>>  Reworded.
>>>
>>>>
>>>>   4.  5.2 Second paragraph
>>>>   Motivation: Deletion of a note in this sentence made it less 
>>>> obvious that we are only talking about directions of use of 
>>>> language communication, and not about establishing asymmetric media 
>>>>   -------------end of 
>>>> change-------------------------------------------
>>>>   There was no agreement to delete them all. The one described in 
>>>> this paragraph is the main one that has widespread use and needs to 
>>>> be clearly specified for use by a large number of hard-of-hearing 
>>>> and deaf users.
>>>
>>>>   Motivation: We are not primarily talking about enabled 
>>>> transmission directions of the streams, but about language use in 
>>>> the streams. We do not want to limit the media stream directions 
>>>> just because we do not specify an initial language to use for that 
>>>> direction. There are other usage of media, and there may even be 
>>>> occasional use of language in the direction, just not worth 
>>>> mentioning as an initial and preferred use. The suggested change 
>>>> should make that clear.
>>>>
>>>>   There is no way specified for indicating use of text based 
>>>> language in a video media stream.
>>>>   There is no meaning assigned to specification of  sign language 
>>>> in an audio or text media stream.
>>>>   Motivation: Seeing the speaker in video is an important 
>>>> combination reinserted above in section 5.2.
>>>>   Supported languages and media and transmission directions 
>>>> are:[list of supported languages and media and transmission 
>>>> directions.]"
>>>>   Motivation: There has not yet been any conclusion for my proposal 
>>>> no 5 in the IETF LC comments of Feb 12.
>>>>   This is a dramatically reduced version that may be easier to 
>>>> accept at this stage, still covering one of the missing 
>>>> functionalities in the draft.
>>>  Making the asterisk a purely-advisory hint as to the 
>>> least-preferred media/language combination seems harmless enough, as 
>>> it would not be required to support it; however, I'm not sure it 
>>> provides any benefit: if an offer contains some set of media with 
>>> language, and the answerer can support all of them, should the 
>>> answerer only include in its answer those without an asterisk? It 
>>> seems simpler for the answerer to include everything in the offer 
>>> that it can support.
>>>
>>
>>  --

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 26 Feb 2017 08:38:36 +0100

Randall,

One more clarification for issue 12 - the asterisk placement as a 
preference hint:

You say:

" it seems better for the answerer to include all media and languages 
from the offer that it can support. "

You are right. I misread this paragraph in section 5.2:
"   In an answer, 'humintlang-send' is the language the answerer will
    send (which in most cases is one of the languages in the offer's
    'humintlang-recv'), and 'humintlang-recv' is the language the
    answerer expects to receive (which in most cases is one of the
    languages in the offer's 'humintlang-send')."

That gave me the impression that I need to answer with only one language 
per direction in the whole SDP.

But in the first paragraph of 5.2, it is said: "to negotiate
    which human language is used*in each interactive media stream*. "

So, we are allowed to include more than one language per direction in 
the SDP, but the users are not expected to use more than one language 
per direction, at least initially in the call.

(that makes the wording "will send" and "expects to receive" in the 
cited paragraph a bit misleading, because as you point out, some of them 
might never be used. "is prepared to send" and "can accept to receive" 
might better correspond to what it means. Ending the sentence with "per 
media steram" might also help to remind the reader about the semantics. 
I leave to you to change these if you want.)

/Gunnar

Den 2017-02-26 kl. 07:46, skrev Gunnar Hellström:
>>>  You did not answer issue 6, use of asymmetrical language rather 
>>> than unidirectional media. I assume you accepted it.
>>
>>> combination is undefined. Nothing in the LC discussion indicated 
>>> that it should be undefined. Why did you suddenly want to delete it? 
>>> It is useful. Please reinsert with the wording changes I propose.
>>
> The idea to differentiate spoken and written cases by script tags 
> caused discussions and was dropped. The remaining real case with the 
> view of the speaker was mentioned twice in the draft, so it was 
> recommended that one of them should be deleted, but not both.
>>
>>>
>>>  Example: A hard-of-hearing user can just barely conduct spoken 
>>> calls with persons she knows. From others it is much more reliable 
>>> to get text.  She calls and declares:
>>>
>>>  m=audio
>>>  a=huml-send:en
>>>  a=huml-recv:en*
>>>  m=text
>>>  a=huml-recv:en
>>>
>>> therefore select the less favoured alternative with using speech 
>>> both ways, answering:
>>>
>>>  m=audio
>>>  a=huml-recv:en
>>>  a=huml-send:en
>>>  m=text 0
>>>
>>> unreliably received. Time and effort would be spent by speech to 
>>> make the answering party switch to sending text instead of talking 
>>> in order to arrange for a more reliable call situation.
>>>
>>>  Then the answering parties without text capability would not dare 
>>> to try to answer, and a reasonably successful call would be missed.
>>>
>>> make call establishment successful and smooth in many more cases 
>>> than without this indication opportunity.
>>>
>> This convinces me that we cannot accept the proposed text, as it 
>> would introduce complexity that the WG explicitly decided to not 
>> pursue in this draft.  In the examples you provided, it seems better 
>> for the answerer to include all media and languages from the offer 
>> that it can support.  This is much simpler, has only trivial 
>> drawbacks (extra media negotiated that might not be used), and is 
>> what the WG agreed to.
> Yes, you could let the answer SDP contain one common language per 
> media and direction, but the answering human need guidance on which 
> language is best suited to start the conversation. Therefore the 
> placement of the asterisk is used to hint the answering party how to 
> start the call.
>
>>>>>> rejected due to no languages in common, SIP response code 488 
>>>>>> (Not Acceptable Here) or 606 (Not Acceptable) be used, along with 
>>>>>> a Warning header field indicating the supported languages.  The 
>>>>> language communication, and not about establishing asymmetric 
>>>>> media connections. Therefore add this clarification.
>>>>
>>>>  Reworded.
>>>>
>>>>>
>>>>> this paragraph is the main one that has widespread use and needs 
>>>>> to be clearly specified for use by a large number of 
>>>>> modality, but the media can become ambigous then, so use media 
>>>>> here to be brief.
>>>>
>>>>>   Motivation: There has not yet been any conclusion for my 
>>>>> proposal no 5 in the IETF LC comments of Feb 12.
>>>>>   The asterisk is used as a preference parameter in the 
>>>>> attributes. Thereby the proposed title change on 5.3
>>>>>   With this additional rule about where the asterisk(s) are 
>>>>> placed, the answering parties get good clues about the preferences 
>>>>> between alternatives presented by the offeror. The chance to set 
>>>>> up calls with satisfied users increase dramatically compared to 
>>>>> letting the answering party select by chance between alternatives.
>>>>
>>>> least-preferred media/language combination seems harmless enough, 
>>>> as it would not be required to support it; however, I'm not sure it

---

From: Randall Gellens <[email-masked]>
Date: Sun, 26 Feb 2017 16:55:59 -0800

At 7:46 AM +0100 2/26/17, Gunnar Hellström wrote:

>>> seeing the speaker in video, it is still a 
>>> huge difference in specifying a preference to 
>>> see the speaker for language perception 
>>> reasons, versus only specifying that I want a 
>>> video stream for supplementary purposes. With 
>>> the current wording in version -07, section 
>>> 5.3 says that that combination is undefined. 
>>> Nothing in the LC discussion indicated that 
>>> it should be undefined. Why did you suddenly 
>>> want to delete it? It is useful. Please 
>>> reinsert with the wording changes I propose.
>>
>>  The email discussion led me to believe that 
>> the text was controversial.  We need to get 
>> the draft finished, so it's better to delete 
>> controversial text than to spend months 
>> fighting about it.
>  The comments were first about the uncertainty 
> about how the "silly states" were to be 
> interpreted.
>  We described them all but decided to only keep 
> the view of the speaker because it is a real 
> and useful case.
>  The idea to differentiate spoken and written 
> cases by script tags caused discussions and was 
> dropped. The remaining real case with the view 
> of the speaker was mentioned twice in the 
> draft, so it was recommended that one of them 
> should be deleted, but not both.

OK, I'll restore the text in section 5.2:

    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.

And modify section 5.4 to exclude this case:

    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.

>>>   "Making the asterisk a purely-advisory hint 
>>> as to the least-preferred media/language 
>>> combination seems harmless enough, as it 
>>> would not be required to support it; however, 
>>> I'm not sure it provides any benefit: if an 
>>> offer contains some set of media with 
>>> language, and the answerer can support all of 
>>> them, should the answerer only include in its 
>>> answer those without an asterisk? It seems 
>>> simpler for the answerer to include 
>>>   Example: A hard-of-hearing user can just 
>>> barely conduct spoken calls with persons she 
>>> knows. From others it is much more reliable 
>>>   The answering party with text capabilities 
>>> sees that matching text for sending is higher 
>>>   The answering party sends the initial 
>>> greeting in text and the call continues 
>>> smoothly in well managed langauage/modality 
>>> combinations.
>>>
>>> capabilities, and may therefore select the 
>>> less favoured alternative with using speech 
>>> both ways, answering:
>>>
>>>   m=audio
>>>   a=huml-recv:en
>>>   a=huml-send:en
>>>   m=text 0
>>>
>>>   If the placement of the asterisk had no 
>>> special meaning as it is in version -07, it 
>>> is a high risk that the answering party in 
>>> the first example would select to answer with 
>>> spoken language that would be unreliably 
>>> received. Time and effort would be spent by 
>>> speech to make the answering party switch to 
>>> sending text instead of talking in order to 
>>> arrange for a more reliable call situation.
>>>
>>> capability would not dare to try to answer, 
>>> and a reasonably successful call would be 
>>> missed.
>>>
>>> alternatives that would make call 
>>> establishment successful and smooth in many 
>>> more cases than without this indication 
>>> opportunity.
>>>
>> proposed text, as it would introduce 
>> complexity that the WG explicitly decided to 
>> not pursue in this draft.  In the examples you 
>> provided, it seems better for the answerer to 
>> include all media and languages from the offer 
>> that it can support.  This is much simpler, 
>> has only trivial drawbacks (extra media 
>> negotiated that might not be used), and is 
>> what the WG agreed to.
>  Yes, you could let the answer SDP contain one 
> common language per media and direction, but 
> the answering human need guidance on which 
> language is best suited to start the 
> conversation. Therefore the placement of the 

I believe the WG discussed proposals to provide 
information to the humans regarding the languages 
and media that were negotiated, and decided it is 
out of scope of the draft as an implementation 
issue, not a protocol issue.

>   Example: A hard-of-hearing user can just 
> barely conduct spoken calls with persons she 
> knows. From others it is much more reliable to 
> get text.  She calls and declares:
>
>   m=audio
>   a=huml-send:en
>   a=huml-recv:en*
>   m=text
>   a=huml-recv:en
>
>   The answering party with capabilities for both 
> written and spoken English sees that matching 
> text for sending is higher preferred than 
>   The answering party makes use of the hint that 
> the caller prefers to receive written text and 
> therefore sends the initial greeting in text 
> and the call continues smoothly in well managed 
> langauage/modality combinations.
>
>  ----------
>  There is no complexity left in this solution, 
> it helps to motivate why we have the asterisk 
> on media level, and it helps to successful call 

My suggestion is that you write this idea as a 
new draft offering implementation guidance, and 
ask the WG to adopt it as either Informational or 
BCP.  It doesn't affect the protocol in the 
current draft, but provides guidance on how to 
use the protocol in both an offer and an answer 
and potentially in the UI.

>>>>>> renaming the two attributes which is 
>>>>>> currently being discussed on the list, and 
>>>>>> adding a new attribute for 
>>>>>> bidirectionality.
>>>>>>
>>>>>> advice that if a call is rejected due to 
>>>>>> no languages in common, SIP response code 
>>>>>> 488 (Not Acceptable Here) or 606 (Not 
>>>>>> languages.  The draft registers a new 
>>>>>> entry in the warn-code sub-registry of SIP 
>>>>>> parameters for this purpose.  The draft 
>>>>>> also has an expanded set of examples.
>>>>>>
>>>>>    Motivation: It was commented that when 
>>>>> the draft is published, this is not new 
>>>>> anymore.
>>>>>    There are three more occasions of "new" 
>>>>> in the document that may be modified as 
>>>>> well.
>>>>
>>>>   OK.
>>>>
>>>>>
>>>>>    3.  5.2 second paragraph
>>>>> "indicate" in two places to match the new 
>>>>> use of plural "values".
>>>>>    Motivation 2:) Be sure to indicate that 
>>>>> we only intend to negotiate one language 
>>>>> per media and direction, so that we do not 
>>>>> end up as unspecified regarding number of 
>>>>> matches required as the sdp "lang" 
>>>>> attribute is.
>>>>
>>>>   Reworded.
>>>>
>>>>>
>>>>>    4.  5.2 Second paragraph
>>>>> exchange a discussion about sharpening up 
>>>>> the specification of use of "unusual 
>>>>> combinations".
>>>>>    There was no agreement to delete them 
>>>>> all. The one described in this paragraph is 
>>>>> the main one that has widespread use and 
>>>>> needs to be clearly specified for use by a 
>>>>> large number of hard-of-hearing and deaf 
>>>>> users.
>>>>
>>>>> about enabled transmission directions of 
>>>>> the streams, but about language use in the 
>>>>> media can become ambigous then, so use 
>>>>> media here to be brief.
>>>>
>>>>>    There is no way specified for indicating 
>>>>> use of text based language in a video media 
>>>>> stream.
>>>>>    Motivation: Seeing the speaker in video 
>>>>> is an important combination reinserted 
>>>>> above in section 5.2.
>>>>   The section is more than just the asterisk, 
>>>> it also advises use of specific SIP response 
>>>>>    This is a dramatically reduced version 
>>>>> that may be easier to accept at this stage, 
>>>>> still covering one of the missing 
>>>>> asterisk(s) are placed, the answering 
>>>>> parties get good clues about the 
>>>>> preferences between alternatives presented 
>>>>> by the offeror. The chance to set up calls 
>>>>> with satisfied users increase dramatically 
>>>>> compared to letting the answering party 
>>>>> select by chance between alternatives.
>>>>
>>>>   Making the asterisk a purely-advisory hint 
>>>> as to the least-preferred media/language 
>>>> combination seems harmless enough, as it 
>>>> would not be required to support it; 
>>>> however, I'm not sure it provides any 
>>>> benefit: if an offer contains some set of 
>>>> media with language, and the answerer can 
>>>> support all of them, should the answerer 
>>>> only include in its answer those without an 
>>>> asterisk? It seems simpler for the answerer 
>>>> to include everything in the offer that it 
>>>> can support.
>>>>
>>>
>>>   --

-------------- Randomly selected tag: ---------------
Tell the pretty ones they're smart, and tell the smart ones they're pretty.
                                       --Mae West's advice on handling men

---

From: Randall Gellens <[email-masked]>
Date: Sun, 26 Feb 2017 17:01:10 -0800

At 8:38 AM +0100 2/26/17, Gunnar Hellström wrote:

>  Randall,
>
>  One more clarification for issue 12 - the 
> asterisk placement as a preference hint:
>
>  You say:
>
>  " it seems better for the answerer to include 
> all media and languages from the offer that it 
> can support. "
>
>  That gave me the impression that I need to 
> answer with only one language per direction in 
> the whole SDP.

It's per media.

>  which human language is used in each interactive media stream. "
>
>  So, we are allowed to include more than one 
> language per direction in the SDP, but the 
> users are not expected to use more than one 
> language per direction, at least initially in 
> the call.

There's nothing in the protocol that says 
anything about people using more than one media 
in each direction.

>  (that makes the wording "will send" and 
> "expects to receive" in the cited paragraph a 
> bit misleading, because as you point out, some 
> of them might never be used. "is prepared to 
> send" and "can accept to receive" might better 
> correspond to what it means. Ending the 
> sentence with "per media steram" might also 
> help to remind the reader about the semantics. 

OK, I'm happy to add the additional clarification.  The paragraph now reads:

    In an answer, 'hlang-send' is the language the answerer will send
    when using the media (which in most cases is one of the languages in
    the offer's 'hlang-recv'), and 'hlang-recv' is the language the
    answerer expects to receive in the media (which in most cases is one
    of the languages in the offer's 'hlang-send').

>>>> huge difference in specifying a preference 
>>>> to see the speaker for language perception 
>>>> reasons, versus only specifying that I want 
>>>> a video stream for supplementary purposes. 
>>>> With the current wording in version -07, 
>>>> section 5.3 says that that combination is 
>>>> undefined. Nothing in the LC discussion 
>>>> indicated that it should be undefined. Why 
>>>> did you suddenly want to delete it? It is 
>> cases by script tags caused discussions and 
>> was dropped. The remaining real case with the 
>> view of the speaker was mentioned twice in the 
>>>> can support."
>>>> with one of the languages that is without 
>>>> the asterisk in the offer. Only if the 
>>>> answering party does not have capability in 
>>>> a language without an asterisk, one with 
>>>> asterisk should be selected. Thereby you get 
>>>> the best opportunity to start the call in a 
>>>> language combination that satisfies both 
>>>> users.
>>>>
>>>> sees that matching text for sending is 
>>>> higher preferred than talking, and thus 
>>>> responds:
>>>>
>>>>  m=audio
>>>>  a=huml-recv:en
>>>>  m=text
>>>>  a=huml-send:en
>>>>
>>>> parties try as well as possible to manage 
>>>> the call in this less preferred combination 
>>>> that may be less reliable.
>>>>
>>>> the first example would select to answer 
>>>> with spoken language that would be 
>>>> unreliably received. Time and effort would 
>>>> be spent by speech to make the answering 
>>>> party switch to sending text instead of 
>>>> talking in order to arrange for a more 
>>>> reliable call situation.
>>>>
>>> include all media and languages from the 
>>> offer that it can support. This is much 
>>> simpler, has only trivial drawbacks (extra 
>> and the call continues smoothly in well 
>> on media level, and it helps to successful 
>> call initiations, so I think it should be 
>> acceptable.
>>
>>  Gunnar
>>
>>>
>>>  --Randy
>>>
>>>>>>> for the unresolved issue of renaming the 
>>>>>>> two attributes which is currently being 
>>>>>>> entry in the warn-code sub-registry of 
>>>>>>> SIP parameters for this purpose. The 
>>>>>>> draft also has an expanded set of 
>>>>>>> examples.
>>>>>>>
>>>>>> media and direction, so that we do not end 
>>>>>> up as unspecified regarding number of 
>>>>>> main one that has widespread use and needs 
>>>>>> to be clearly specified for use by a large 
>>>>> anything and explicitly mentions 
>>>>> negotiating supplemental video by omitting 
>>>>> language attributes on a video media.
>>>>>
>>>>>>
>>>>>>  6. 5.2 Sixth paragraph
>>>>>> specify an initial language to use for 
>>>>>> that direction. There are other usage of 
>>>>>> media, and there may even be occasional 
>>>>>> use of language in the direction, just not 
>>>>>> worth mentioning as an initial and 
>>>>>> preferred use. The suggested change should 
>>>>>> make that clear.
>>>>>>
>>>>> I'll add SHOULD kist supported languages 
>>>>> and media. Demanding direction as well 
>>>>> might be too unwieldy.
>>>>>
>>>>>>
>>>>>>  8. 5.3, last line
>>>>>> use of text based language in a video 
>>>>>> media stream.
>>>>>> an important combination reinserted above 
>>>>>> in section 5.2.
>>>>> it also advises use of specific SIP 
>>>>> response codes if the call is failed.
>>>>>
>>>>>>
>>>>>> in 
>>>>>> conclusion for my proposal no 5 in the 
>>>>>> IETF LC comments of Feb 12.
>>>>>> that may be easier to accept at this 
>>>>>> stage, still covering one of the missing 
>>>>  <mailto:[email-masked]>[email-masked]
>>>>  +46 708 204 288
>>>>
>>>
>>>
>>
>
>  --
>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288

-------------- Randomly selected tag: ---------------
I would suggest that there is s very significant danger that
they have listened to us!
    --Comments during a Federal Open Market Committee meeting in 2004

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 27 Feb 2017 09:01:10 +0100

Randall,
good to see that we are converging,
Den 2017-02-27 kl. 01:55, skrev Randall Gellens:
>>>> that it should be undefined. Why did you suddenly want to delete 
>>>> it? It is useful. Please reinsert with the wording changes I propose.
>>>
>>  We described them all but decided to only keep the view of the 
>> speaker because it is a real and useful case.
Addison did not like the expression "spoken/written language tag" when 
we used it in the discussion about section 5.4.
We may get the same reaction here.
You would have avoided it if you took my wording proposal as it was.
>>>>   The answering party with text capabilities sees that matching 
>>>> text for sending is higher preferred than talking, and thus responds:
>>>>
>>>>   m=audio
>>>>   a=huml-recv:en
>>>>   m=text
>>>>   a=huml-send:en
>>>>
>>>>   The answering party sends the initial greeting in text and the 
>>>> call continues smoothly in well managed langauage/modality 
>>>> combinations.
>>>>
>>>>   If the placement of the asterisk had no special meaning as it is 
>>>> in version -07, it is a high risk that the answering party in the 
>>>> first example would select to answer with spoken language that 
>>>> would be unreliably received. Time and effort would be spent by 
>>>> speech to make the answering party switch to sending text instead 
>>>> of talking in order to arrange for a more reliable call situation.
>>>>
> I believe the WG discussed proposals to provide information to the 
> humans regarding the languages and media that were negotiated, and 
> decided it is out of scope of the draft as an implementation issue, 
> not a protocol issue.
Yes, we did, and said that the mechanism for providing the result of the 
indication and negotiation to the user is out of scope, but the 
resulting information needs to be provided to the user. It is the user 
who generates language and the user needs to know the most preferred 
common languages so that the user can start the call in an appropriate 
language.
This is valid for the language as well as the preference indication.

And we say that by the end of section 1. " Both sides should be aware of 
which language was negotiated."    No mechanism specified, but the 
result needs to be conveyed to the user.

Now, when there is no required protocol influence implied by the 
placement of the asterisk, all feared complexity is gone and only the 
huge increase in usability remains.

It is not fair that users who want to express preference between 
languages in a single modality can do it, but users who have preferences 
between languages in different modalities cannot indicate that. Let us 
cover that gap when it is so free from complexity to do it.

>> calls with persons she knows. From others it is much more reliable to 
>>   The answering party makes use of the hint that the caller prefers 
>> to receive written text and therefore sends the initial greeting in 
>> text and the call continues smoothly in well managed 
>>  There is no complexity left in this solution, it helps to motivate 
>> why we have the asterisk on media level, and it helps to successful 
>> call initiations, so I think it should be acceptable.
>
> My suggestion is that you write this idea as a new draft offering 
> implementation guidance, and ask the WG to adopt it as either 
> Informational or BCP.  It doesn't affect the protocol in the current 
> draft, but provides guidance on how to use the protocol in both an 
> offer and an answer and potentially in the UI.
I suggest that the chairs and area director assign a procedure suitable 
for the current state of the draft to potentially include the meaning of 
the placement of the asterisk as proposed in my issue 12.

Thanks
Gunnar
>>>>>>>    Per Dale's suggestion, the draft adds advice that if a call 
>>>>>>> is rejected due to no languages in common, SIP response code 488 
>>>>>>> (Not Acceptable Here) or 606 (Not Acceptable) be used, along 
>>>>>>> with a Warning header field indicating the supported languages.  
>>>>>>> The draft registers a new entry in the warn-code sub-registry of 
>>>>>>> SIP parameters for this purpose.  The draft also has an expanded 
>>>>>>> set of examples.
>>>>>>>
>>>>>>    There are three more occasions of "new" in the document that 
>>>>>> may be modified as well.
>>>>>
>>>>>   OK.
>>>>>
>>>>>>
>>>>>>    3.  5.2 second paragraph
>>>>>>    Motivation: There was in the LC mail exchange a discussion 
>>>>>> about sharpening up the specification of use of "unusual 
>>>>>> combinations".
>>>>>>    There was no agreement to delete them all. The one described 
>>>>>> in this paragraph is the main one that has widespread use and 
>>>>>> needs to be clearly specified for use by a large number of 
>>>>>> just because we do not specify an initial language to use for 
>>>>>> that direction. There are other usage of media, and there may 
>>>>>> even be occasional use of language in the direction, just not 
>>>>>> worth mentioning as an initial and preferred use. The suggested 
>>>>>> change should make that clear.
>>>>>>
>>>>> supported languages and media. Demanding direction as well might 
>>>>> be too unwieldy.
>>>>>
>>>>>>
>>>>>>    8.      5.3, last line
>>>>>   The section is more than just the asterisk, it also advises use 
>>>>> of specific SIP response codes if the call is failed.
>>>>>
>>>>>>
>>>>>> placed, the answering parties get good clues about the 
>>>>>> preferences between alternatives presented by the offeror. The 
>>>>>> chance to set up calls with satisfied users increase dramatically 
>>>>>> compared to letting the answering party select by chance between 
>>>>>> alternatives.
>>>>>
>>>>> as it would not be required to support it; however, I'm not sure 
>>>>> it provides any benefit: if an offer contains some set of media 
>>>>> with language, and the answerer can support all of them, should 
>>>>> the answerer only include in its answer those without an asterisk? 
>>>>> It seems simpler for the answerer to include everything in the 
>>>>> offer that it can support.
>>>>>
>>>>
>>>>   --

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 27 Feb 2017 14:37:40 +0100

Den 2017-02-27 kl. 02:01, skrev Randall Gellens:
>>  " it seems better for the answerer to include all media and 
>> languages from the offer that it can support. "
>>
>>  That gave me the impression that I need to answer with only one 
>> language per direction in the whole SDP.
>
> It's per media.
>
>
>>  So, we are allowed to include more than one language per direction 
>> in the SDP, but the users are not expected to use more than one 
>> language per direction, at least initially in the call.
>
> There's nothing in the protocol that says anything about people using 
> more than one media in each direction.
>
>
>> cited paragraph a bit misleading, because as you point out, some of 
>> them might never be used. "is prepared to send" and "can accept to 
>> receive" might better correspond to what it means. Ending the 
>> sentence with "per media steram" might also help to remind the reader 
>> about the semantics. I leave to you to change these if you want.)
>

Yes, that might be acceptable if "will send when using the media" can be 
read as being conditional: "will send if use of the media for language 
purposes is selected",
but not if it is read as a definite usage "will send for the periods of 
time that this media will definitively be used for language 
communication."  With the latter interpretation we have not improved our 
logic over the lang attribute that could be interpreted as it required 
use of all declared languages in the session.

I still think it is safer to say "is prepared to send" instead of "will 
send".
While for the other direction, I think the "expects to receive" is vague 
enough to mean that another media might be used.

Sorry for continuing to watch out for logic gaps here.

Gunnar
>>>>> With the current wording in version -07, section 5.3 says that 
>>>>> that combination is undefined. Nothing in the LC discussion 
>>>>> indicated that it should be undefined. Why did you suddenly want 
>>>>> to delete it? It is useful. Please reinsert with the wording 
>>>>> changes I propose.
>>>>>
>>>>
>>>>> offer that it can support."
>>>>>
>>>>> asterisk, one with asterisk should be selected. Thereby you get 
>>>>> the best opportunity to start the call in a language combination 
>>>>> that satisfies both users.
>>>>>
>>>>> possible to manage the call in this less preferred combination 
>>>>>>>> The draft registers a new entry in the warn-code sub-registry 
>>>>>>>> of SIP parameters for this purpose. The draft also has an 
>>>>>>>> expanded set of examples.
>>>>>>>>
>>>>>>> negotiate one language per media and direction, so that we do 
>>>>>>> not end up as unspecified regarding number of matches required 
>>>>>>> as the sdp "lang" attribute is.
>>>>>>>
>>>>>>
>>>>>>  Reworded.
>>>>>>
>>>>>>>
>>>>>>>  4. 5.2 Second paragraph
>>>>>>> transmission directions of the streams, but about language use 
>>>>>>> in the streams. We do not want to limit the media stream 
>>>>>>> directions just because we do not specify an initial language to 
>>>>>>> use for that direction. There are other usage of media, and 
>>>>>>> there may even be occasional use of language in the direction, 
>>>>>>> just not worth mentioning as an initial and preferred use. The 
>>>>>>> suggested change should make that clear.
>>>>>>>
>>>>>>> chance to set up calls with satisfied users increase 
>>>>>>> dramatically compared to letting the answering party select by 
>>>>>>> chance between alternatives.
>>>>>>>
>>>>>>
>>>>>> the answerer only include in its answer those without an 
>>>>>> asterisk? It seems simpler for the answerer to include everything 
>>>>>> in the offer that it can support.
>>>>>>
>>>>>
>>>>>  --

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Feb 2017 07:31:52 -0800

At 9:01 AM +0100 2/27/17, Gunnar Hellström wrote:

>>>>>    On 5, the request to reinsert wording 
>>>>> about seeing the speaker in video, it is 
>>>>> still a huge difference in specifying a 
>>>>> preference to see the speaker for language 
>>>>> perception reasons, versus only specifying 
>>>>> that I want a video stream for 
>>>>> supplementary purposes. With the current 
>>>>> wording in version -07, section 5.3 says 
>>>>> that that combination is undefined. Nothing 
>>>>> in the LC discussion indicated that it 
>>>>> should be undefined. Why did you suddenly 
>>>   The comments were first about the 
>>> uncertainty about how the "silly states" were 
>>> to be interpreted.
>>>   We described them all but decided to only 
>>> keep the view of the speaker because it is a 
>>> real and useful case.
>>> view of the speaker was mentioned twice in 
>>> the draft, so it was recommended that one of 
>>> them should be deleted, but not both.
>>
>  Addison did not like the expression 
> "spoken/written language tag" when we used it 
> in the discussion about section 5.4.
>>>>> media/language combination seems harmless 
>>>>> enough, as it would not be required to 
>>>>> support it; however, I'm not sure it 
>>>>> provides any benefit: if an offer contains 
>>>>> some set of media with language, and the 
>>>>> answerer can support all of them, should 
>>>>> the answerer only include in its answer 
>>>>> those without an asterisk? It seems simpler 
>>>>> for the answerer to include everything in 
>>>>> the offer that it can support."
>>>>>
>>>>>    The answering party should aim at 
>>>>> answering with one of the languages that is 
>>>>> without the asterisk in the offer. Only if 
>>>>> the answering party does not have 
>>>>> capability in a language without an 
>>>>> asterisk, one with asterisk should be 
>>>>> selected. Thereby you get the best 
>>>>> barely conduct spoken calls with persons 
>>>>> she knows. From others it is much more 
>>>>> reliable to get text.  She calls and 
>>>>> declares:
>>>>>
>>>>>    m=audio
>>>>>    a=huml-send:en
>>>>>    a=huml-recv:en*
>>>>>    m=text
>>>>>    a=huml-recv:en
>>>>>
>>>>>    Many other similar realistic examples can 
>>>>> be created, where placement of the 
>>>>> asterisk(s) would be a sufficient 
>>>>> indication of lower preference for language 
>>>>> match among alternatives that would make 
>>>>> call establishment successful and smooth in 
>>>>> many more cases than without this 
>>>>> indication opportunity.
>>>>>
>>>> not pursue in this draft.  In the examples 
>>>> you provided, it seems better for the 
>>>> answerer to include all media and languages 
>>>> from the offer that it can support.  This is 
>>>> much simpler, has only trivial drawbacks 
>>>> (extra media negotiated that might not be 
>>>> used), and is what the WG agreed to.
>>>   Yes, you could let the answer SDP contain 
>>> one common language per media and direction, 
>>> but the answering human need guidance on 
>>> which language is best suited to start the 
>>  I believe the WG discussed proposals to 
>> provide information to the humans regarding 
>> the languages and media that were negotiated, 
>> and decided it is out of scope of the draft as 
>> an implementation issue, not a protocol issue.
>  Yes, we did, and said that the mechanism for 
> providing the result of the indication and 
> negotiation to the user is out of scope, but 
> the resulting information needs to be provided 
> to the user. It is the user who generates 
> language and the user needs to know the most 
> preferred common languages so that the user can 
> start the call in an appropriate language.
>  And we say that by the end of section 1. " Both 
> sides should be aware of which language was 
> negotiated."    No mechanism specified, but the 
>  Now, when there is no required protocol 
> influence implied by the placement of the 
> asterisk, all feared complexity is gone and 
> only the huge increase in usability remains.
>
>  It is not fair that users who want to express 
> preference between languages in a single 
> modality can do it, but users who have 
> preferences between languages in different 
> modalities cannot indicate that. Let us cover 
> that gap when it is so free from complexity to 
> do it.

Conveying information to the user is UI which is out of scope of this draft.

>>>    The answering party with capabilities for 
>>> both written and spoken English sees that 
>>> matching text for sending is higher preferred 
>>> than talking and sends the answer indicating 
>>> the capabilities:
>>>
>>>    m=audio
>>>    a=huml-recv:en
>>>   a=huml-send:en
>>>    m=text
>>>    a=huml-send:en
>>>
>>>    The answering party makes use of the hint 
>>> that the caller prefers to receive written 
>>> text and therefore sends the initial greeting 
>>> in text and the call continues smoothly in 
>>> well managed langauage/modality combinations.
>>>
>>>   ----------
>>>   There is no complexity left in this 
>>> solution, it helps to motivate why we have 
>>> the asterisk on media level, and it helps to 
>>> successful call initiations, so I think it 
>>> should be acceptable.
>>
>> new draft offering implementation guidance, 
>> and ask the WG to adopt it as either 
>> Informational or BCP.  It doesn't affect the 
>> protocol in the current draft, but provides 
>> guidance on how to use the protocol in both an 
>  I suggest that the chairs and area director 
> assign a procedure suitable for the current 
> state of the draft to potentially include the 
> meaning of the placement of the asterisk as 
> proposed in my issue 12.

UI is out of scope of the draft.  If you write an 
"advice to implementers" type document, that can 
accomplish your goal.

>>>>>>>> currently being discussed on the list, 
>>>>>>>> and adding a new attribute for 
>>>>>>>> bidirectionality.
>>>>>>>>
>>>>>>>> no languages in common, SIP response 
>>>>>>>> code 488 (Not Acceptable Here) or 606 
>>>>>>>> (Not Acceptable) be used, along with a 
>>>>>>>     Motivation 1:) change from "indicates" 
>>>>>>> to "indicate" in two places to match the 
>>>>>>> new use of plural "values".
>>>>>>> language per media and direction, so that 
>>>>>>> we do not end up as unspecified regarding 
>>>>>>> number of matches required as the sdp 
>>>>>>> "lang" attribute is.
>>>>>>
>>>>>>    Reworded.
>>>>>>
>>>>>>>
>>>>>>>     4.  5.2 Second paragraph
>>>>>>> establishing asymmetric media 
>>>>>>> all. The one described in this paragraph 
>>>>>>> is the main one that has widespread use 
>>>>>>> and needs to be clearly specified for use 
>>>>>>> by a large number of hard-of-hearing and 
>>>>>>> deaf users.
>>>>>>
>>>>>>> directions of the streams, but about 
>>>>>>> language use in the streams. We do not 
>>>>>>> want to limit the media stream directions 
>>>>>>> language to use for that direction. There 
>>>>>>> are other usage of media, and there may 
>>>>>>> even be occasional use of language in the 
>>>>>>> direction, just not worth mentioning as 
>>>>>>> an initial and preferred use. The 
>>>>>>>     Motivation: It is not sufficient to 
>>>>>>> know which languages are supported, it is 
>>>>>>> also essential to know in which media 
>>>>>>> they are supported and in which 
>>>>>>> directions. (media could be replaced with 
>>>>>>> modality, but the media can become 
>>>>>>    I don't know that we can require this, 
>>>>>> but I'll add SHOULD kist supported 
>>>>>> languages and media. Demanding direction 
>>>>>> as well might be too unwieldy.
>>>>>>
>>>>>>>
>>>>>>>     8.      5.3, last line
>>>>>>> transmission in audio; es, en reception 
>>>>>>> in audio"
>>>>>>>     There is no way specified for 
>>>>>>> indicating use of text based language in 
>>>>>>> a video media stream.
>>>>>>> specification of sign language in an 
>>>>>>>     This section therefore needed 
>>>>>>> rewording to not include that combination.
>>>>>>
>>>>>>    The section is more than just the 
>>>>>> asterisk, it also advises use of specific 
>>>>>> SIP response codes if the call is failed.
>>>>>>
>>>>>>>
>>>>>>>     With this additional rule about where 
>>>>>>> the asterisk(s) are placed, the answering 
>>>>>>> preferences between alternatives 
>>>>>>> presented by the offeror. The chance to 
>>>>>>> set up calls with satisfied users 
>>>>>>> increase dramatically compared to letting 
>>>>>>> the answering party select by chance 
>>>>>>> between alternatives.
>>>>>>
>>>>>> media/language combination seems harmless 
>>>>>> enough, as it would not be required to 
>>>>>> support it; however, I'm not sure it 
>>>>>> provides any benefit: if an offer contains 
>>>>>> some set of media with language, and the 
>>>>>> answerer can support all of them, should 
>>>>>> the answerer only include in its answer 

-------------- Randomly selected tag: ---------------
Some days you feel like Schrodinger's cat.   --M. S. Hutchenreuther

---

From: Randall Gellens <[email-masked]>
Date: Mon, 27 Feb 2017 07:34:03 -0800

At 2:37 PM +0100 2/27/17, Gunnar Hellström wrote:

>>>   " it seems better for the answerer to 
>>> offer that it can support. "
>>>
>>> answer with only one language per direction 
>>> in the whole SDP.
>>
>>  It's per media.
>>
>> anything about people using more than one 
>> media in each direction.
>>
>>> bit misleading, because as you point out, 
>>> some of them might never be used. "is 
>>> prepared to send" and "can accept to receive" 
>>> might better correspond to what it means. 
>>> Ending the sentence with "per media steram" 
>>> might also help to remind the reader about 
>>> the semantics. I leave to you to change these 
>>> if you want.)
>>
>  Yes, that might be acceptable if "will send 
> when using the media" can be read as being 
> conditional: "will send if use of the media for 
> language purposes is selected",
>  but not if it is read as a definite usage "will 
> send for the periods of time that this media 
> will definitively be used for language 
> communication."  With the latter interpretation 
> we have not improved our logic over the lang 
> attribute that could be interpreted as it 
> required use of all declared languages in the 
> session.

I think "when using the media" is clear.

>
>  I still think it is safer to say "is prepared 
> to send" instead of "will send".
>  While for the other direction, I think the 
> "expects to receive" is vague enough to mean 
> that another media might be used.
>
>>>>>> that that combination is undefined. 
>>>>>> Nothing in the LC discussion indicated 
>>>>>> that it should be undefined. Why did you 
>>>>>> suddenly want to delete it? It is useful. 
>>>>>> Please reinsert with the wording changes I 
>>>>>> propose.
>>>>>>
>>>>>
>>>>>   The email discussion led me to believe 
>>>>> that the text was controversial. We need to 
>>>>> get the draft finished, so it's better to 
>>>> uncertainty about how the "silly states" 
>>>> were to be interpreted.
>>>> discussions and was dropped. The remaining 
>>>> real case with the view of the speaker was 
>>>> mentioned twice in the draft, so it was 
>>>>>> answering with one of the languages that 
>>>>>> is without the asterisk in the offer. Only 
>>>>>> if the answering party does not have 
>>>>>> opportunity to start the call in a 
>>>>>> smoothly in well managed 
>>>>>> less favoured alternative with using 
>>>>>> speech both ways, answering:
>>>>>>
>>>>>>   m=audio
>>>>>>   a=huml-recv:en
>>>>>>   a=huml-send:en
>>>>>>   m=text 0
>>>>>>
>>>>>> the call in this less preferred 
>>>>>> combination that may be less reliable.
>>>>>>
>>>>>> special meaning as it is in version -07, 
>>>>>> it is a high risk that the answering party 
>>>>>> in the first example would select to 
>>>>>> answer with spoken language that would be 
>>>>>> capability would not dare to try to 
>>>>>> answer, and a reasonably successful call 
>>>>>> would be missed.
>>>>>>
>>>>>> indication of lower preference for 
>>>>>> language match among alternatives that 
>>>>>> would make call establishment successful 
>>>>>> and smooth in many more cases than without 
>>>>>> this indication opportunity.
>>>>>>
>>>>>   This convinces me that we cannot accept 
>>>>> the proposed text, as it would introduce 
>>>>> complexity that the WG explicitly decided 
>>>>> to not pursue in this draft. In the 
>>>>> examples you provided, it seems better for 
>>>>> the answerer to include all media and 
>>>>> languages from the offer that it can 
>>>>> support. This is much simpler, has only 
>>>>> trivial drawbacks (extra media negotiated 
>>>>> that might not be used), and is what the WG 
>>>>> agreed to.
>>>>>
>>>> matching text for sending is higher 
>>>> preferred than talking and sends the answer 
>>>> indicating the capabilities:
>>>>
>>>>   m=audio
>>>>   a=huml-recv:en
>>>>   a=huml-send:en
>>>>   m=text
>>>>   a=huml-send:en
>>>>
>>>> text and therefore sends the initial 
>>>>>>>>> advice that if a call is rejected due 
>>>>>>>>> to no languages in common, SIP response 
>>>>>>>> per media and direction, so that we do 
>>>>>>>> not end up as unspecified regarding 
>>>>>>>> sentence made it less obvious that we 
>>>>>>>> are only talking about directions of use 
>>>>>>>> of language communication, and not about 
>>>>>>>> exchange a discussion about sharpening 
>>>>>>>> up the specification of use of "unusual 
>>>>>>>> combinations".
>>>>>>>> and needs to be clearly specified for 
>>>>>>>> use by a large number of hard-of-hearing 
>>>>>>>> and deaf users.
>>>>>>>>
>>>>>>>
>>>>>>> negotiating supplemental video by 
>>>>>>> omitting language attributes on a video 
>>>>>>> media.
>>>>>>>
>>>>>>>>
>>>>>>>>   6. 5.2 Sixth paragraph
>>>>>>>> want to limit the media stream 
>>>>>>>> directions just because we do not 
>>>>>>>> use of language in the direction, just 
>>>>>>>> not worth mentioning as an initial and 
>>>>>>>> preferred use. The suggested change 
>>>>>>>> should make that clear.
>>>>>>>>
>>>>>>>> know which languages are supported, it 
>>>>>>>> is also essential to know in which media 
>>>>>>>> directions. (media could be replaced 
>>>>>>>> the asterisk(s) are placed, the 
>>>>>>>> answering parties get good clues about 
>>>>>>>> the preferences between alternatives 
>>>>>>>> increase dramatically compared to 
>>>>>>> provides any benefit: if an offer 
>>>>>>> contains some set of media with language, 
>>>>>>> and the answerer can support all of them, 
>>>>>>> should the answerer only include in its 
>>>>>>> answer those without an asterisk? It 
>>>>>>> seems simpler for the answerer to include 

-------------- Randomly selected tag: ---------------
This is a nasty, rotten business.
    --Robert L. Crandall, CEO & President of American Airlines

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 27 Feb 2017 23:53:35 +0100

Den 2017-02-27 kl. 16:31, skrev Randall Gellens:
>>>>>>    You did not answer issue 6, use of asymmetrical language 
>>>>>> rather than unidirectional media. I assume you accepted it.
>>>>>
>>>>>>    On 5, the request to reinsert wording about seeing the speaker 
>>>>>> in video, it is still a huge difference in specifying a 
>>>>>> preference to see the speaker for language perception reasons, 
>>>>>> versus only specifying that I want a video stream for 
>>>>>> supplementary purposes. With the current wording in version -07, 
>>>>>> section 5.3 says that that combination is undefined. Nothing in 
>>>>>> the LC discussion indicated that it should be undefined. Why did 
>>>>>> you suddenly want to delete it? It is useful. Please reinsert 
>>>>> controversial.  We need to get the draft finished, so it's better 
>>>>> to delete controversial text than to spend months fighting about it.
>>>>   The comments were first about the uncertainty about how the 
>>>> "silly states" were to be interpreted.
>>>> caused discussions and was dropped. The remaining real case with 
>>>> the view of the speaker was mentioned twice in the draft, so it was 
>>  Addison did not like the expression "spoken/written language tag" 
>> when we used it in the discussion about section 5.4.
>>>>>> in the offer that it can support."
>>>>>>
>>>>>> calls with persons she knows. From others it is much more 
>>>>>> reliable to get text.  She calls and declares:
>>>>>>
>>>>>>    m=audio
>>>>>>    a=huml-send:en
>>>>>>    a=huml-recv:en*
>>>>>>    m=text
>>>>>>    a=huml-recv:en
>>>>>>
>>>>>>    The answering party starts taking and the parties try as well 
>>>>>> as possible to manage the call in this less preferred combination 
>>>>>>    If the placement of the asterisk had no special meaning as it 
>>>>>> is in version -07, it is a high risk that the answering party in 
>>>>>> the first example would select to answer with spoken language 
>>>>>> that would be unreliably received. Time and effort would be spent 
>>>>>> by speech to make the answering party switch to sending text 
>>>>>> instead of talking in order to arrange for a more reliable call 
>>>>>> situation.
>>>>>>
>>>>>>    Then the answering parties without text capability would not 
>>>>>> dare to try to answer, and a reasonably successful call would be 
>>>>>> missed.
>>>>>>
>>>>> pursue in this draft.  In the examples you provided, it seems 
>>>>> better for the answerer to include all media and languages from 
>>>>> the offer that it can support.  This is much simpler, has only 
>>>>> trivial drawbacks (extra media negotiated that might not be used), 
>>>>> and is what the WG agreed to.
>>>> placement of the asterisk is used to hint the answering party how 
>>>> to start the call.
>>>
>>  Yes, we did, and said that the mechanism for providing the result of 
>> the indication and negotiation to the user is out of scope, but the 
>> resulting information needs to be provided to the user. It is the 
>> user who generates language and the user needs to know the most 
>> preferred common languages so that the user can start the call in an 
>> appropriate language.
>>  And we say that by the end of section 1. " Both sides should be 
>> aware of which language was negotiated."    No mechanism specified, 
>> but the result needs to be conveyed to the user.
>>
>> languages in a single modality can do it, but users who have 
>> preferences between languages in different modalities cannot indicate 
>> that. Let us cover that gap when it is so free from complexity to do it.
>
We are talking about protocol just as much as for specifying the 
languages. We are not saying how the result of language negotiation is 
provided to the user, because the procedure is out of scope. But we say 
that the user must be made aware of the result of the indication and 
negotiation. Otherwise they will not be able to start the call in the 
preferred language. Both languages and preferences need to be indicated 
to the users.
All resulting information need to be conveyed to the user and we do not 
say how for any of the items, we just say that that is the intention of 
sending all these indications.

Please be positive to the minimal proposal we are down to now, adding a 
sentence and changing the title of section 5.3, and let us ask our 
chairs for the correct procedure to include it.

/Gunnar

>>>>    The answering party with capabilities for both written and 
>>>> spoken English sees that matching text for sending is higher 
>>>> preferred than talking and sends the answer indicating the 
>>>> capabilities:
>>>>
>>>>    m=audio
>>>>    a=huml-recv:en
>>>>   a=huml-send:en
>>>>    m=text
>>>>    a=huml-send:en
>>>>
>>>>    The answering party makes use of the hint that the caller 
>>>> prefers to receive written text and therefore sends the initial 
>>>> greeting in text and the call continues smoothly in well managed 
>>>>   There is no complexity left in this solution, it helps to 
>>>> motivate why we have the asterisk on media level, and it helps to 
>>>> successful call initiations, so I think it should be acceptable.
>>>
>>  I suggest that the chairs and area director assign a procedure 
>> suitable for the current state of the draft to potentially include 
>> the meaning of the placement of the asterisk as proposed in my issue 12.
>
> UI is out of scope of the draft.  If you write an "advice to 
> implementers" type document, that can accomplish your goal.
>
>
>
>>
>>  Thanks
>>  Gunnar
>>>
>>>
>>>
>>>>>
>>>>>>>>>     Version -07 addresses all comments except for the 
>>>>>>>>> unresolved issue of renaming the two attributes which is 
>>>>>>>>> currently being discussed on the list, and adding a new 
>>>>>>>>>     Per Dale's suggestion, the draft adds advice that if a 
>>>>>>>>> call is rejected due to no languages in common, SIP response 
>>>>>>>>> code 488 (Not Acceptable Here) or 606 (Not Acceptable) be 
>>>>>>>>> used, along with a Warning header field indicating the 
>>>>>>>>> supported languages.  The draft registers a new entry in the 
>>>>>>>>> warn-code sub-registry of SIP parameters for this purpose.  
>>>>>>>>> The draft also has an expanded set of examples.
>>>>>>>>>
>>>>>>>>     Motivation: It was commented that when the draft is 
>>>>>>>> published, this is not new anymore.
>>>>>>>>     There are three more occasions of "new" in the document 
>>>>>>>> that may be modified as well.
>>>>>>>
>>>>>>>    OK.
>>>>>>>
>>>>>>>>
>>>>>>>>     3.  5.2 second paragraph
>>>>>>>>     Motivation: Deletion of a note in this sentence made it 
>>>>>>>> less obvious that we are only talking about directions of use 
>>>>>>>> of language communication, and not about establishing 
>>>>>>>> asymmetric media connections. Therefore add this clarification.
>>>>>>>
>>>>>>>    Reworded.
>>>>>>>
>>>>>>>>
>>>>>>>>     There was no agreement to delete them all. The one 
>>>>>>>> described in this paragraph is the main one that has widespread 
>>>>>>>> use and needs to be clearly specified for use by a large number 
>>>>>>>> of hard-of-hearing and deaf users.
>>>>>>>
>>>>>>>    The text as it is now does not prohibit anything and 
>>>>>>> explicitly mentions negotiating supplemental video by omitting 
>>>>>>>> directions just because we do not specify an initial language 
>>>>>>>> to use for that direction. There are other usage of media, and 
>>>>>>>>     Motivation: It is not sufficient to know which languages 
>>>>>>>> are supported, it is also essential to know in which media they 
>>>>>>>> are supported and in which directions. (media could be replaced 
>>>>>>>> with modality, but the media can become ambigous then, so use 
>>>>>>>> media here to be brief.
>>>>>>>
>>>>>>>    I don't know that we can require this, but I'll add SHOULD 
>>>>>>> kist supported languages and media. Demanding direction as well 
>>>>>>> might be too unwieldy.
>>>>>>>
>>>>>>>>
>>>>>>>>     8.      5.3, last line
>>>>>>>>      Supported languages are: es, en transmission in audio; es, 
>>>>>>>> en reception in audio"
>>>>>>>>     There is no meaning assigned to specification of sign 
>>>>>>>> language in an audio or text media stream.
>>>>>>>    The section is more than just the asterisk, it also advises 
>>>>>>> use of specific SIP response codes if the call is failed.
>>>>>>>
>>>>>>>>
>>>>>>>>     This is a dramatically reduced version that may be easier 
>>>>>>>> to accept at this stage, still covering one of the missing 
>>>>>>> least-preferred media/language combination seems harmless 
>>>>>>> enough, as it would not be required to support it; however, I'm 
>>>>>>> not sure it provides any benefit: if an offer contains some set 
>>>>>>> of media with language, and the answerer can support all of 
>>>>>>> them, should the answerer only include in its answer those 
>>>>>>> without an asterisk? It seems simpler for the answerer to

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 27 Feb 2017 23:58:38 +0100

Den 2017-02-27 kl. 16:34, skrev Randall Gellens:
>>>>   So, we are allowed to include more than one language per 
>>>> direction in the SDP, but the users are not expected to use more 
>>>> than one language per direction, at least initially in the call.
>>>
>>>  There's nothing in the protocol that says anything about people 
>>> using more than one media in each direction.
>>>
>>>>   (that makes the wording "will send" and "expects to receive" in 
>>>> the cited paragraph a bit misleading, because as you point out, 
>>>> some of them might never be used. "is prepared to send" and "can 
>>>> accept to receive" might better correspond to what it means. Ending 
>>>> the sentence with "per media steram" might also help to remind the 
>>>> reader about the semantics. I leave to you to change these if you 
>>>> want.)
>>>
>>  Yes, that might be acceptable if "will send when using the media" 
>> can be read as being conditional: "will send if use of the media for 
>>  but not if it is read as a definite usage "will send for the periods 
>> of time that this media will definitively be used for language 
>> communication."  With the latter interpretation we have not improved 
>> our logic over the lang attribute that could be interpreted as it 
>> required use of all declared languages in the session.
>
I hope you are right. I stop arguing about this one.
Thanks
Gunnar
>
>>
>>  I still think it is safer to say "is prepared to send" instead of 
>> "will send".
>>  While for the other direction, I think the "expects to receive" is 
>> vague enough to mean that another media might be used.
>>
>>>>>   The idea to differentiate spoken and written cases by script 
>>>>> tags caused discussions and was dropped. The remaining real case 
>>>>> with the view of the speaker was mentioned twice in the draft, so 
>>>>> it was recommended that one of them should be deleted, but not both.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> include everything in the offer that it can support."
>>>>>>>
>>>>>>> answering party does not have capability in a language without 
>>>>>>> an asterisk, one with asterisk should be selected. Thereby you 
>>>>>>> get the best opportunity to start the call in a language 
>>>>>>> as possible to manage the call in this less preferred 
>>>>>>> that would be unreliably received. Time and effort would be 
>>>>>>> spent by speech to make the answering party switch to sending 
>>>>>>> text instead of talking in order to arrange for a more reliable 
>>>>>>> call situation.
>>>>>>>
>>>>>>> lower preference for language match among alternatives that 
>>>>>>> would make call establishment successful and smooth in many more 
>>>>>>> cases than without this indication opportunity.
>>>>>>>
>>>>>>   This convinces me that we cannot accept the proposed text, as 
>>>>>> it would introduce complexity that the WG explicitly decided to 
>>>>>> not pursue in this draft. In the examples you provided, it seems 
>>>>>> trivial drawbacks (extra media negotiated that might not be 
>>>>>   Yes, you could let the answer SDP contain one common language 
>>>>> per media and direction, but the answering human need guidance on 
>>>>> which language is best suited to start the conversation. Therefore 
>>>>> the placement of the asterisk is used to hint the answering party 
>>>>> how to start the call.
>>>>>
>>>>>>>>>> is rejected due to no languages in common, SIP response code 
>>>>>>>>>> 488 (Not Acceptable Here) or 606 (Not Acceptable) be used, 
>>>>>>>>>> along with a Warning header field indicating the supported 
>>>>>>>>>> languages. The draft registers a new entry in the warn-code 
>>>>>>>>>> sub-registry of SIP parameters for this purpose. The draft 
>>>>>>>>> supported, it is also essential to know in which media they 
>>>>>>>>> are supported and in which directions. (media could be 
>>>>>>>>> replaced with modality, but the media can become ambigous 
>>>>>>>>> then, so use media here to be brief.
>>>>>>>>>
>>>>>>>>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 28 Feb 2017 17:08:50 -0800

Hi Gunnar,

I'm starting a new message to cut out the huge amount of quoting.

Your proposal is that text be added that advises the calling client 
to place an asterisk on the least-preferred language/media, and 
advises the answering client to indicate to the answering human which 
language/media is not the least preferred (did not have an asterisk 
in the offer), is that accurate?

-------------- Randomly selected tag: ---------------
If you would look up bad labor relations in the dictionary, you
would have an American Airlines logo beside it.
    --U.S. District Judge Joe Kendall, issuing a restraining order
against an American Airlines APA pilot union sick out, 10 Feb 1999.

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 1 Mar 2017 08:26:56 +0100

Hi Randall,
Den 2017-03-01 kl. 02:08, skrev Randall Gellens:
> Your proposal is that text be added that advises the calling client to 
> place an asterisk on the least-preferred language/media, and advises 
> the answering client to indicate to the answering human which 
> language/media is not the least preferred (did not have an asterisk in 
> the offer), is that accurate?
Yes, with slight rewording to:
"text that advises the *offering* client to place an asterisk on the 
least-preferred language/media *indications*, and advises the answering 
client to indicate to the answering human which language/media are not 
the least preferred (did not have an asterisk in the offer)"

The inclusion of the "indications" is just to assure that it is clear 
that it does not need to be just one indication that gets the asterisk .
The last part sounds awkward, but matches technically what the lack of 
an asterisk means. I inherited the inverted logic for the asterisk from 
its already defined non-denial meaning.
If you are considering wording for the draft, I suggest that you 
straighten the logic to say "*which language/media are most preferred 
(did not have an asterisk in the offer)*"

It does also not need to be an "answering human" that gets this 
indication and makes use of it for guidance on how to answer the call. 
It can just as well be e.g. a multi-modal answering machine or some 
other application interacting with human language. I am not sure if 
"*answering party*" is more appropriate and can be considered including 
such automata.

Thanks,
Gunnar