Subject: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language

From: Bernard Aboba <[email-masked]>
Date: Sat, 18 Nov 2017 10:46:15 -0800

At this point, only a single Issue (43) remains open on
draft-ietf-slim-negotiating-human-language::
https://trac.ietf.org/trac/slim/ticket/43

This relates to the modality of a language indication.

Currently, Gunnar has suggested a modification to the text of Section 5.4
in order to address the issue:
https://mailarchive.ietf.org/arch/msg/slim/A4b6Wpgh0Z0zpXKqpwF9bfdW35g

Can WG participants review this suggested change, so that we can determine
how to move forward?

Currently, Section 5.4 states that:

   The problem of knowing which language tags are signed and which are
   not is out of scope of this document.

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 18 Nov 2017 23:33:11 +0100

Thanks Bernard for pushing for closing the last open issue.
Den 2017-11-18 kl. 19:46, skrev Bernard Aboba:
> Currently, Gunnar has suggested a modification to the text of Section 
> 5.4 in order to address the issue:
> Can WG participants review this suggested change, so that we can 
> determine how to move forward?
>
I earlier thought that an application needed to look into the language 
subtag Description to find the word "sign" there in the text string. 
That is not a good solution. But when studying the topic again in RFC 
5646 I found that there is a consistent machine-implementable way to 
assess if a language subtag is for a sign language.
Therefore I included this text in the latest proposal for section 5.4 at 
the link that Bernard provided:

"

A specific sign language can be identified by its existence in the IANA
registry of language subtags according to BCP 47 [RFC5646] , and finding
that the language subtag is found at least in two entries in the
registry, once with the Type field "language" and once with the Type
field "extlang" combined with the Prefix field value "sgn".

"

So that should be the response on Dales request to easily decide if a 
language tag is for a sign language.

Worse is next topic in issue 43: to assess if a language tag is for a 
spoken modality or written modality of a language.
My wording proposal starts with the obvious cases: a non-signed languge 
tag in audio media is spoken, and a non-signed language tag in text 
media is written.  But for other cases, like in video or message or 
application or multiplexed media, other indications must be used to 
understand the intended modality. The proposed text mentions a few, and 
leaves to applications to decide which mechanisms to use for such cases. 
I wish we for the ambiguous cases could use the script subtag -zxxx to 
indicate spoken modality and a real script subtag even on language 
subtags where script subtags are suppressed, because that would satisfy 
issue 43 nicely and make section 5.4 much shorter and clearer. But we 
have had resistance against that solution.

The proposed text might be a bit long and detailed. I am prepared to 
agree on a shortened version if there are any proposals. I think though 
that contents of 5.4 in the direction of my proposal is what satisfies  
issue 43 and also the comments lately that section 5.4 is too restrictive.

/Gunnar

>
>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 18 Nov 2017 21:24:53 -0800

Gunnar said:

"I earlier thought that an application needed to look into the language
subtag Description to find the word "sign" there in the text string. That
is not a good solution."

[BA] Agreed. Also, as indicated in RFC 5646 Section 4.1.2 and the IANA
registry (
https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry),
sign languages may not have always have a subtag of 'sgn':

   Sign languages share a mode of communication rather than a linguistic
   heritage.  There are many sign languages that have developed
   independently, and the subtag 'sgn' indicates only the presence of a
   sign language.  A number of sign languages also had grandfathered
   tags registered for them during the RFC 3066
<https://tools.ietf.org/html/rfc3066> era.  For example, the
   grandfathered tag "sgn-US" was registered to represent 'American Sign
   Language' specifically, without reference to the United States.  This
   is still valid, but deprecated: a document in American Sign Language
   can be labeled either "ase" or "sgn-ase" (the 'ase' subtag is for the
   language called 'American Sign Language').

Gunnar also said:

"A specific sign language can be identified by its existence in the IANA

So that should be the response on Dales request to easily decide if a
language tag is for a sign language. "

[BA]  Looking at the IANA registry, having a Type field "extlang" combined
with the Prefix field value 'sgn' seems to be used as an indicator of a
sign language.  Do you think we can rely on this? Currently this is only a
SHOULD  in RFC 5646 Section 3.4:

            3.  Sign languages SHOULD have an 'extlang' record with
an'Prefix' of 'sgn'.

"My wording proposal starts with the obvious cases: a non-signed
language tag in audio media is spoken, and a non-signed language tag
in text media is written."

[BA] Assuming your suggested approach allows us to reliably determine
non-sign languages, this seems solid.

Gunnar further said:

"But for other cases, like in video or message or application or
multiplexed media, other indications must be used to

understand the intended modality... I wish for the ambiguous cases we
could use the script subtag -zxxx to indicate

spoken modality and a real script subtag..."

[BA] This is where I become uneasy, because without an explicit
mechanism such as script subtags, there is the potential for
ambiguity.

Trying to address reduce that ambiguity via heuristics could turn out
to be a bad idea, compared with proceeding more cautiously

by leaving behavior undefined for now and revisiting the situation
later when we understand the problem better. For example:

"Use for sending of a visual view of a speaking person may be
indicated by the value "speaker" in an SDP
Content attribute according to RFC 4796 [RFC4796] in a "video" media
stream or another media carrying video (e.g. "message" or
"application")."

[BA] There are quite a few potential corner cases here. For example,
if "en-US" language is included in an offer within a video m-line,
should the answerer assume this implies a willingness to lip read US
English if the value "speaker" is in the Content attribute?  What can
be assumed if a value other than "speaker" is in the Content
attribute? Might that represent something entirely different, such as
the desire to receive captioning in US English? If so, how could the
Offerer indicate both the capability of lipreading and the ability to
handle captions? And what happens if the Answerer doesn't mimic the
Content attribute in the Offer? Seems like there are some potential
"gotchas" here.

"Use of written modality in another media stream than

"text", may be discriminated by use of a script subtag in the language
tag, where that is appropriate."

[BA] What if the language in question has script subtags suppressed?
What if the Offerer includes a script subtag in the video m-line but
also "speaker" in the Content attribute? Again, there could be quite a
few corner cases lurking here.

On Sat, Nov 18, 2017 at 2:33 PM, Gunnar Hellström <
[email-masked]> wrote:

> subtag Description to find the word "sign" there in the text string. That
> is not a good solution. But when studying the topic again in RFC 5646 I
> found that there is a consistent machine-implementable way to assess if a
> language subtag is for a sign language.
> tag in audio media is spoken, and a non-signed language tag in text media
> is written.  But for other cases, like in video or message or application
> or multiplexed media, other indications must be used to understand the
> intended modality. The proposed text mentions a few, and leaves to
> applications to decide which mechanisms to use for such cases. I wish we
> for the ambiguous cases could use the script subtag -zxxx to indicate
> spoken modality and a real script subtag even on language subtags where
> script subtags are suppressed, because that would satisfy issue 43 nicely
> and make section 5.4 much shorter and clearer. But we have had resistance
> against that solution.
>
> The proposed text might be a bit long and detailed. I am prepared to agree
> on a shortened version if there are any proposals. I think though that
> contents of 5.4 in the direction of my proposal is what satisfies  issue 43
> and also the comments lately that section 5.4 is too restrictive.
>
> /Gunnar
>
>
>
>
>
>
> SLIM mailing [email-masked]://www.ietf.org/mailman/listinfo/slim
>
>
> --
> [email-masked]
> +46 708 204 288
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 19 Nov 2017 11:40:48 +0100

Den 2017-11-19 kl. 06:24, skrev Bernard Aboba:
> Gunnar said:
>
> "I earlier thought that an application needed to look into the 
> language subtag Description to find the word "sign" there in the text 
> string. That is not a good solution."
>
> registry 
> (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry), 
>     tags registered for them during theRFC 3066 <https://tools.ietf.org/html/rfc3066>  era.  For example, the
<GH>Right. It cannot be seen by the language tag itself if it is a sign 
language. You need to interrogate the IANA registry.
> language tag is for a sign language."
>
> [BA]  Looking at the IANA registry, having a Type field "extlang" 
> combined with the Prefix field value 'sgn' seems to be used as an 
> indicator of a sign language.  Do you think we can rely on this? 
> Currently this is only a SHOULD  in RFC 5646 Section 3.4:
>
>              3.  Sign languages SHOULD have an 'extlang' record with an'Prefix' of 'sgn'.
<GH>Yes, it is a SHOULD. But all registered sign languages so far follow 
this rule, so I think it is solid. Do you think we need to weaken the 
start of our recommended procedure:

"A specific sign language can be identified...."   The "can" could be weakened, but I do not think we need to do so.

> in text media is written."
<GH>Among the three obvious cases are also that sign languages in video 
media are signed.
> [BA] Assuming your suggested approach allows us to reliably determine non-sign languages, this seems solid.
> Gunnar further said:
> "But for other cases, like in video or message or application or multiplexed media, other indications must be used to
> understand the intended modality... I wish for the ambiguous cases we could use the script subtag -zxxx to indicate
> [BA] This is where I become uneasy, because without an explicit mechanism such as script subtags, there is the potential for ambiguity.
> Trying to address reduce that ambiguity via heuristics could turn out to be a bad idea, compared with proceeding more cautiously
> by leaving behavior undefined for now and revisiting the situation later when we understand the problem better. For example:
> "Use for sending of a visual view of a speaking person may be indicated by the value "speaker" in an SDP
> Content attribute according to RFC 4796 [RFC4796] in a "video" media stream or another media carrying video (e.g. "message" or "application")."
> [BA] There are quite a few potential corner cases here. For example, if "en-US" language is included in an offer within a video m-line, should the answerer assume this implies a willingness to lip read US English if the value "speaker" is in the Content attribute?  What can be assumed if a value other than "speaker" is in the Content attribute? Might that represent something entirely different, such as the desire to receive captioning in US English? If so, how could the Offerer indicate both the capability of lipreading and the ability to handle captions? And what happens if the Answerer doesn't mimic the Content attribute in the Offer? Seems like there are some potential "gotchas" here.
<GH>Yes, I agree that the hint to use the "Content" attribute was not 
solid. One problem with it is that it is said to indicate only what is 
to be sent in the media, so we have no way to use it for desired 
received modality. Thereby it cannot be used as a confirmation from the 
answering party. So it is a weak hint and may confuse more than it helps.
The idea was however to be informative guide to a number of possible 
ways for applications to indicate modality when it is not one of the 
three obvious cases. We can delete the hint about the "Content" attribute.
> [BA] What if the language in question has script subtags suppressed? What if the Offerer includes a script subtag in the video m-line but also "speaker" in the Content attribute? Again, there could be quite a few corner cases lurking here.
<GH> The application must not create illogical combinations. But let us 
drop the "Content" attribute hint. I find the use of the script subtag 
much more solid for the otherwise ambiguous cases. RFC 5646 clearly says 
that it is allowed to use even suppressed script subtags when its use 
has an important discriminating meaning. (Section 4.1 of RFC 5646 says:

        "The script subtag SHOULD NOT be used to form language tags unless
        the script adds some distinguishing information to the tag."

That is true for our case. The problem is that we have had persistent 
resistance from the language experts for both using suppressed script 
substags for written modality and using the -Zxxx script subtag for 
spoken modality.  Can we explain our case better and get a go ahead from 
the language experts? That would result in a really simple set of rules.

Gunnar

>   
>
> On Sat, Nov 18, 2017 at 2:33 PM, Gunnar Hellström 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     <https://trac.ietf.org/trac/slim/ticket/43>
>>
>>     Currently, Gunnar has suggested a modification to the text of
>>     Section 5.4 in order to address the issue:
>>     <https://mailarchive.ietf.org/arch/msg/slim/A4b6Wpgh0Z0zpXKqpwF9bfdW35g>
>>
>>
>     I earlier thought that an application needed to look into the
>     language subtag Description to find the word "sign" there in the
>     text string. That is not a good solution. But when studying the
>     topic again in RFC 5646 I found that there is a consistent
>     machine-implementable way to assess if a language subtag is for a
>     sign language.
>     Therefore I included this text in the latest proposal for section
>     5.4 at the link that Bernard provided:
>
>     "
>
>     So that should be the response on Dales request to easily decide
>     if a language tag is for a sign language.
>
>     Worse is next topic in issue 43: to assess if a language tag is
>     for a spoken modality or written modality of a language.
>     My wording proposal starts with the obvious cases: a non-signed
>     languge tag in audio media is spoken, and a non-signed language
>     tag in text media is written.  But for other cases, like in video
>     or message or application or multiplexed media, other indications
>     must be used to understand the intended modality. The proposed
>     text mentions a few, and leaves to applications to decide which
>     mechanisms to use for such cases. I wish we for the ambiguous
>     cases could use the script subtag -zxxx to indicate spoken
>     modality and a real script subtag even on language subtags where
>     script subtags are suppressed, because that would satisfy issue 43
>     nicely and make section 5.4 much shorter and clearer. But we have
>     had resistance against that solution.
>
>     The proposed text might be a bit long and detailed. I am prepared
>     to agree on a shortened version if there are any proposals. I
>     think though that contents of 5.4 in the direction of my proposal
>     is what satisfies  issue 43 and also the comments lately that
>     section 5.4 is too restrictive.
>
>     /Gunnar
>
>
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/slim>
>
>     -- 
>     [email-masked] <mailto:[email-masked]>
>     +46 708 204 288
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Nov 2017 09:27:45 -0800

On Nov 19, 2017, at 2:40 AM, Gunnar Hellström <[email-masked]> wrote:

>> <GH>Yes, it is a SHOULD. But all registered sign languages so
>>     far follow this rule, so I think it is solid. Do you think we need
>>     to weaken the start of our recommended procedure: 

[BA] As you say, it does appear that the rule is being followed. But perhaps we can find an expert to confirm this.

> <GH>Among the three obvious cases are also that sign languages in video media are signed.

[BA] Yes.

> <GH> The application must not create illogical combinations. But let us drop the "Content" attribute hint. I find the use of the script subtag much more solid for the otherwise ambiguous cases. RFC 5646 clearly says that it is allowed to use even suppressed script subtags when its use has an important discriminating meaning. (Section 4.1 of RFC 5646 says:
> That is true for our case. 
> Can we explain our case better and get a go ahead from the language experts? That would result in a really simple set of rules. 

[BA] It seems like an important point to clarify.  Let me try to figure out how we can get expert consultation.

---

From: "Phillips, Addison" <[email-masked]>
Date: Sun, 19 Nov 2017 23:07:23 +0000

A few points.

1.       Sign languages do not necessarily use the subtag ‘sgn’. In fact, most sign languages have subtags that have nothing to do with the ‘sgn’ subtag. They are not ‘extlang’ and do not have a macrolanguage of ‘sgn’. For example, here is the record for American Sign Language:

%%
Type: language
Subtag: ase
Description: American Sign Language
Added: 2009-07-29
%%

2.       Sign languages may have the words “Sign Language” in one of their Description fields (notice that I say “one of”). I’m not sure that all sign languages have this. Someone would have to ask the ISO 639 folks if there are any outliers.

3.       Suppress-Script is an advisory field in the registry. It does not cause or require that the script subtag be omitted. It is also an incomplete bit of documentation: many languages that fit the criteria for Suppress-Script do not have the field in the registry. Use or non-use of the script subtag is not a very reliable indicator of language modality on its own. Tags like “en-US” or “de” function well for identifying the language of various materials and I caution folks that, in my experience, arcane rules about the specialized use of subtags are likely to be ignored.

Overall, my suggestion would be: if you need to deal with modality, don’t use (existing) language subtags for it. Encode metadata to make things explicit. Use private use subtags or an extension for it if you must. But don’t provide super-special meaning for subtags. Personally, I tend to think you should encode modality on a different level. Someone who is hard of hearing and low vision has different needs from a blind user who has different needs from a deaf person with limited mobility… etc.

Addison

From: SLIM [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Saturday, November 18, 2017 9:25 PM
To: Gunnar Hellström <[email-masked]>
Cc: [email-masked]
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language

Gunnar said:

"I earlier thought that an application needed to look into the language subtag Description to find the word "sign" there in the text string. That is not a good solution."

[BA] Agreed. Also, as indicated in RFC 5646 Section 4.1.2 and the IANA registry (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry), sign languages may not have always have a subtag of 'sgn':

   tags registered for them during the RFC 3066<https://tools.ietf.org/html/rfc3066> era.  For example, the

Gunnar also said:

So that should be the response on Dales request to easily decide if a language tag is for a sign language. "

[BA]  Looking at the IANA registry, having a Type field "extlang" combined with the Prefix field value 'sgn' seems to be used as an indicator of a sign language.  Do you think we can rely on this? Currently this is only a SHOULD  in RFC 5646 Section 3.4:

"My wording proposal starts with the obvious cases: a non-signed language tag in audio media is spoken, and a non-signed language tag in text media is written."

Gunnar further said:

On Sat, Nov 18, 2017 at 2:33 PM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Bernard for pushing for closing the last open issue.
Den 2017-11-18 kl. 19:46, skrev Bernard Aboba:

At this point, only a single Issue (43) remains open on draft-ietf-slim-negotiating-human-language::
https://trac.ietf.org/trac/slim/ticket/43

Currently, Gunnar has suggested a modification to the text of Section 5.4 in order to address the issue:
https://mailarchive.ietf.org/arch/msg/slim/A4b6Wpgh0Z0zpXKqpwF9bfdW35g

Can WG participants review this suggested change, so that we can determine how to move forward?

   not is out of scope of this document.
I earlier thought that an application needed to look into the language subtag Description to find the word "sign" there in the text string. That is not a good solution. But when studying the topic again in RFC 5646 I found that there is a consistent machine-implementable way to assess if a language subtag is for a sign language.
Therefore I included this text in the latest proposal for section 5.4 at the link that Bernard provided:

"

So that should be the response on Dales request to easily decide if a language tag is for a sign language.

Worse is next topic in issue 43: to assess if a language tag is for a spoken modality or written modality of a language.
My wording proposal starts with the obvious cases: a non-signed languge tag in audio media is spoken, and a non-signed language tag in text media is written.  But for other cases, like in video or message or application or multiplexed media, other indications must be used to understand the intended modality. The proposed text mentions a few, and leaves to applications to decide which mechanisms to use for such cases. I wish we for the ambiguous cases could use the script subtag -zxxx to indicate spoken modality and a real script subtag even on language subtags where script subtags are suppressed, because that would satisfy issue 43 nicely and make section 5.4 much shorter and clearer. But we have had resistance against that solution.

The proposed text might be a bit long and detailed. I am prepared to agree on a shortened version if there are any proposals. I think though that contents of 5.4 in the direction of my proposal is what satisfies  issue 43 and also the comments lately that section 5.4 is too restrictive.

/Gunnar

SLIM mailing list

[email-masked]<mailto:[email-masked]>

--

Gunnar Hellström

Omnitor

[email-masked]<mailto:[email-masked]>

+46 708 204 288

---

From: Randall Gellens <[email-masked]>
Date: Sun, 19 Nov 2017 15:52:47 -0800

My view of issue #43 remains that we do not need to specify a 
mechanism for determining which tags are signed.  In the email 
discussion of the past month or so, I fear we are drifting into 
adding complexity rather than removing it.  I think the way forward 
is to keep this document as simple as possible.  As Bernard notes in 
his email of 10/23, there is no benefit in this case of explicitly 
saying that certain things are not defined.  Since the document does 
not define them, they are undefined in the document.

At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>  In other words,it is not clear to me how Section 5.4's discussion 
> of scope improves or clarifies the situation in any way - and there 
> is some possibility that it could cause problems.

I believe comment #43 should be closed as no longer applicable, since 
the text against which it was generated has been deleted.  (I've said 
this before, and I believe it remains the case.)

The comment from which #43 derives was made against a version of the 
document that had text explicitly discussing signed versus unsigned 
tags.  That text was subsequently deleted.

Here is the comment from which #43 derived:

>     5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>
>     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 there's a similar paragraph in 5.4:
>
>>     A spoken language tag for a video stream in conjunction with an
>  audio
>>     stream with the same language might indicate a request for
>>     supplemental video to see the speaker.
>
>  I think this mechanism needs to be described more exactly, and in
>  particular, it should not depend on the UA understanding which
>  language tags are spoken language tags.  It seems to me that a
>  workable rule is that there is an audio stream and a video stream and
>  they specify exactly the same language tag in their respective
>  humintlang attributes.  In that case, it is a request for a spoken
>  language with simultaneous video of the speaker, and those requests
>  should be considered satisfied only if both streams can be
>  established.

The offending text that was in 5.2 and 5.4 was deleted.

The only remaining text that even mentions the issue is Section 5.4:

    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 in this document.

So, let's delete Section 5.4 and be done with it.  Neither of the 
statements is necessary.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Make it right before you make it faster.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Nov 2017 19:47:25 -0800

"So let's delete Section 5.4 and be done with it.  Neither of the
statements is necessary."

[BA]  I agree that Section 5.4 does not add much value as it stands.

"Non-signed" is not used outside of Section 5.4, so there would not appear
to be a need to define it if Section 5.4 were to be deleted.

However, the term "signed" is used in 7 other places in the document other
than in Section 5.4.

So we may need to find a reference to define that term.

If Gunnar's suggested definition can be confirmed,  this might be as simple
as adding a reference to the IANA language tag repository.

On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens <[email-masked]>
wrote:

> My view of issue #43 remains that we do not need to specify a mechanism
> for determining which tags are signed.  In the email discussion of the past
> month or so, I fear we are drifting into adding complexity rather than
> removing it.  I think the way forward is to keep this document as simple as
> possible.  As Bernard notes in his email of 10/23, there is no benefit in
> this case of explicitly saying that certain things are not defined.  Since
> the document does not define them, they are undefined in the document.
>
>>  In other words,it is not clear to me how Section 5.4's discussion of
>> scope improves or clarifies the situation in any way - and there is some
>> possibility that it could cause problems.
>>
>
>
> I believe comment #43 should be closed as no longer applicable, since the
> text against which it was generated has been deleted.  (I've said this
> before, and I believe it remains the case.)
>
> document that had text explicitly discussing signed versus unsigned tags.
> That text was subsequently deleted.
>

---

From: Randall Gellens <[email-masked]>
Date: Mon, 20 Nov 2017 06:55:11 -0800

At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:

>  "Non-signed" is not used outside of Section 5.4, so there would not 
> appear to be a need to define it if Section 5.4 were to be deleted.
>
>  However, the term "signed" is used in 7 other places in the 
> document other than in Section 5.4.

But none of those instances are normative.

>  So we may need to find a reference to define that term.

Because the uses of the term are descriptive and mostly background, I 
do not think we need to add a definition or even a reference to a 
definition of the term.

--Randall

>
>  If Gunnar's suggested definition can be confirmed,  this might be 
> as simple as adding a reference to the IANA language tag repository.
>
>  On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens 
> <<mailto:[email-masked]>[email-masked]> wrote:
>
> is to keep this document as simple as possible.  As Bernard notes 
> in his email of 10/23, there is no benefit in this case of 
> explicitly saying that certain things are not defined.  Since the 
> document does not define them, they are undefined in the document.
>
>  I believe comment #43 should be closed as no longer applicable, 
> since the text against which it was generated has been deleted. 
> (I've said this before, and I believe it remains the case.)
>
>  The comment from which #43 derives was made against a version of 
> the document that had text explicitly discussing signed versus 
> unsigned tags.  That text was subsequently deleted.
>

-------------- Randomly selected tag: ---------------
You see, wire telegraph is a kind of very, very long cat.  You
pull his tail in New York and his head is meowing in Los Angeles.
Do you understand this?  And radio operates in exactly the same
way: you send signals here, they receive them there.  The only
difference is that there is no cat.            --Albert Einstein

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 20 Nov 2017 17:07:43 +0100

Addison, thanks for guidance,

Den 2017-11-20 kl. 00:07, skrev Phillips, Addison:
>
> A few points.
>
> 1.Sign languages do not necessarily use the subtag ‘sgn’. In fact, 
> most sign languages have subtags that have nothing to do with the 
> ‘sgn’ subtag. They are not ‘extlang’ and do not have a macrolanguage 
> of ‘sgn’. For example, here is the record for American Sign Language:
>
> %%
>
> Type: language
>
> Subtag: ase
>
<GH>But all sign languages appear again in the registry registered as 
type "extlang" with Prefix value "sgn"
e.g. for American Sign Language :

%%
Type: extlang
Subtag: ase
Preferred-Value: ase
Prefix: sgn
%%

Therefore the procedure to assess if a language is a sign language I 
have proposed is to search the registry for this combination. The 
procedure could be formalized to use the recommendations about "extlang 
form" described in RFC 5646 section 4.5 on canonicalization (not for 
sending the tag, but when evaluating a tag).

> 2.Sign languages may have the words “Sign Language” in one of their 
> Description fields (notice that I say “one of”). I’m not sure that all 
> sign languages have this. Someone would have to ask the ISO 639 folks 
> if there are any outliers.
>
<GH>Yes, but the rule about Prefix: sgn above is much more suitable for 
use in a procedure for finding out the modality. The description string 
could possibly just be used when telling the human parties what the 
result of the negotiation was.
>
> 3.Suppress-Script is an advisory field in the registry. It does not 
> cause or require that the script subtag be omitted. It is also an 
> incomplete bit of documentation: many languages that fit the criteria 
> for Suppress-Script do not have the field in the registry. Use or 
> non-use of the script subtag is not a very reliable indicator of 
> language modality on its own. Tags like “en-US” or “de” function well 
> for identifying the language of various materials and I caution folks 
> that, in my experience, arcane rules about the specialized use of 
> subtags are likely to be ignored.
>
> Overall, my suggestion would be: if you need to deal with modality, 
> don’t use (existing) language subtags for it. Encode metadata to make 
> things explicit. Use private use subtags or an extension for it if you 
> must. But don’t provide super-special meaning for subtags. Personally, 
> I tend to think you should encode modality on a different level. 
> Someone who is hard of hearing and low vision has different needs from 
> a blind user who has different needs from a deaf person with limited 
> mobility… etc.
>
<GH>From the discussion above, we can distinguish sign languages, and 
thereby signed modality without using any extra subtags in the attributes.

But we cannot reliably distinguish between the sound of spoken language 
and a view of a speaking person without applying more subtle indications 
like what media subtypes there are specified etc, and that carries us 
too far away from the request in issue #43 to have a simple way for 
applications to assess the modality.

So, in summary, I suggest that we in section 5.4 describe:
1. The three obvious cases:  written modality  in text media, spoken in 
audio and signed in video ( including an indication on how sign language 
is identified.)
I think it is important to make the reader aware of that it is only for 
these three obvious cases that we have a solution, and that justifies a 
place for section 5.4 but with far less detail than my latest proposal.

2.  Tell that other cases can be defined in specific applications or by 
further work.

Thanks,
Gunnar
>
> Addison
>
> *From:*SLIM [mailto:[email-masked]] *On Behalf Of *Bernard Aboba
> *Sent:* Saturday, November 18, 2017 9:25 PM
> *To:* Gunnar Hellström <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Slim] Moving forward on 
> draft-ietf-slim-negotiating-human-language
>
> Gunnar said:
>
> mechanism such as script subtags, there is the potential for ambiguity.
> stream or another media carrying video (e.g. "message" or "application")."

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 20 Nov 2017 18:25:07 +0100

It is not the signed languages that are causing the problem. It is the 
spoken and written, when used in other media than the obvious audio and 
text media.

And we should specify what is obvious and well defined and not, so here 
is a new shorter proposal for section 5.4.

-----Old text----

      5.4 Undefined Combinations

-----New text------------
5.4 Media, Language and Modality indications

The combination of Language tags and other information in the media 
descriptions should be composed so that the intended modality can be 
concluded by the negotiating parties. The following combinations of 
language tags and media provide obvious information about the modality: 
sign language tags in video media indicate signed modality, spoken 
language tags for audio media indicate spoken modality and written 
language tags for text media indicate written modality. The examples in 
this specification are all from this set of three obvious 
language/media/modality combinations.

A sign language can be identified by the existence in the IANA registry 
of language subtags according to BCP 47 [RFC5646] of the language subtag 
with the Type field "extlang" combined with the Prefix field value "sgn".
A specific spoken or written language can be identified by not having 
any such "sgn" Prefix.

Use of language may appear in other media, such as "message" and 
"application". Video media may be used for other modalities than signed. 
Such use may be supported by further work or application specific 
agreements or indications for evaluation of the intended modality.

-------------------------------------------------------------------End 
of new text---------------------------------------
Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>>  However, the term "signed" is used in 7 other places in the document 
>> other than in Section 5.4.
>
>>  If Gunnar's suggested definition can be confirmed,  this might be as 
>> simple as adding a reference to the IANA language tag repository.
>>
>> since the text against which it was generated has been deleted. (I've 
>> said this before, and I believe it remains the case.)
>>

---

From: Randall Gellens <[email-masked]>
Date: Mon, 20 Nov 2017 10:14:29 -0800

At 6:25 PM +0100 11/20/17, Gunnar Hellström wrote:

>  It is not the signed languages that are causing 
> the problem. It is the spoken and written, when 
> used in other media than the obvious audio and 
> text media.

I am not convinced that this is a problem that 
the draft needs to have text for.  As Bernard 
noted in an earlier email, it doesn't really 
matter if the draft attempts to limit what can be 
done.

Let's delete section 5.4, close issue #43, and advance the draft.

--Randall

>
>  And we should specify what is obvious and well 
> defined and not, so here is a new shorter 
> proposal for section 5.4.
>
>  -----Old text----
>
>  The combination of Language tags and other 
> information in the media descriptions should be 
> composed so that the intended modality can be 
> concluded by the negotiating parties. The 
> following combinations of language tags and 
> media provide obvious information about the 
> modality: sign language tags in video media 
> indicate signed modality, spoken language tags 
> for audio media indicate spoken modality and 
> written language tags for text media indicate 
> written modality. The examples in this 
> specification are all from this set of three 
> obvious language/media/modality combinations.
>
>  A sign language can be identified by the 
> existence in the IANA registry of language 
> subtags according to BCP 47 [RFC5646] of the 
> language subtag with the Type field "extlang" 
> combined with the Prefix field value "sgn".
>  A specific spoken or written language can be 
> identified by not having any such "sgn" Prefix.
>
>  Use of language may appear in other media, such 
> as "message" and "application". Video media may 
> be used for other modalities than signed. Such 
> use may be supported by further work or 
> application specific agreements or indications 
> for evaluation of the intended modality.
>
> 
> of new 
> text---------------------------------------
>
>>>  "So let's delete Section 5.4 and be done with 
>>> it. Neither of the statements is necessary."
>>>
>>>  "Non-signed" is not used outside of Section 
>>> 5.4, so there would not appear to be a need 
>>> to define it if Section 5.4 were to be 
>>> deleted.
>>>
>>>  However, the term "signed" is used in 7 other 
>>> places in the document other than in Section 
>>> 5.4.
>>>
>>
>>  Because the uses of the term are descriptive 
>> and mostly background, I do not think we need 
>> to add a definition or even a reference to a 
>> definition of the term.
>>
>>  --Randall
>>
>>>
>>>  If Gunnar's suggested definition can be 
>>> confirmed, this might be as simple as adding 
>>> a reference to the IANA language tag 
>>> repository.
>>>
>>> <<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>[email-masked]> 
>>> wrote:
>>>
>>>  My view of issue #43 remains that we do not 
>>> need to specify a mechanism for determining 
>>> which tags are signed. In the email 
>>> discussion of the past month or so, I fear we 
>>> are drifting into adding complexity rather 
>>> than removing it. I think the way forward is 
>>> to keep this document as simple as possible. 
>>> As Bernard notes in his email of 10/23, there 
>>> is no benefit in this case of explicitly 
>>> saying that certain things are not defined. 
>>> Since the document does not define them, they 
>>> are undefined in the document.
>>>
>>>  In other words,it is not clear to me how 
>>> Section 5.4's discussion of scope improves or 
>>> clarifies the situation in any way - and 
>>> there is some possibility that it could cause 
>>> problems.
>>>
>>>
>>>
>>>  I believe comment #43 should be closed as no 
>>> longer applicable, since the text against 
>>> which it was generated has been deleted. 
>>>  The comment from which #43 derives was made 
>>> against a version of the document that had 
>>> text explicitly discussing signed versus 
>>>  So, let's delete Section 5.4 and be done with 
>>> it. Neither of the statements is necessary.
>>>
>>>  --
>>>  Randall Gellens
>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288

-------------- Randomly selected tag: ---------------
As far as the laws of mathematics refer to reality, they are not
certain; and as far as they are certain, they do not refer to reality.
                                                    --Albert Einstein

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Nov 2017 10:41:06 -0800

Gunnar said:

"5.4 Media, Language and Modality indications

The combination of Language tags and other information in the media
descriptions should be composed so that the intended modality can be
concluded by the negotiating parties. "

[BA] Is the "should" intended to be normative?

The following combinations of language tags and media provide obvious
information about the modality: sign language tags in video media indicate
signed modality... A sign language can be identified by the existence in
the IANA registry of language subtags according to BCP 47 [RFC5646] of the
language subtag with the Type field "extlang" combined with the Prefix
field value "sgn".  A specific spoken or written language can be identified
by not having any such "sgn" Prefix.

Use of language may appear in other media, such as "message" and
"application". Video media may be used for other modalities than signed.
Such use may be supported by further work or application specific
agreements or indications for evaluation of the intended modality. "

[BA] Assume we can confirm the mechanism for distinguishing
signed/non-signed languages, this part seems relatively solid.

spoken language tags for audio media indicate spoken modality and written
language tags for text media indicate written modality. The examples in
this specification are all from this set of three obvious
language/media/modality combinations.

[BA]  This is where the ground gets less solid - we don't really have a
general mechanism for distinguishing spoken and written modality among
non-signed languages. Perhaps we should just say "language tags in audio
media indicate spoken modality and language tags in text media indicate
written modality".

On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellström <
[email-masked]> wrote:

> And we should specify what is obvious and well defined and not, so here is
> a new shorter proposal for section 5.4.
>
> -----Old text----
>
> sign language tags in video media indicate signed modality, spoken language
> tags for audio media indicate spoken modality and written language tags for
> text media indicate written modality. The examples in this specification
> are all from this set of three obvious language/media/modality combinations.
>
> A sign language can be identified by the existence in the IANA registry of
> language subtags according to BCP 47 [RFC5646] of the language subtag with
> the Type field "extlang" combined with the Prefix field value "sgn".
> A specific spoken or written language can be identified by not having any
> such "sgn" Prefix.
>
> -------------------------------------------------------------------End of
> new text---------------------------------------
>
> Because the uses of the term are descriptive and mostly background, I do
> not think we need to add a definition or even a reference to a definition
> of the term.
>
> --Randall
>
>
>  On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens <<mailto:rg+ietf@randy.
> pensive.org> <[email-masked]>[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Nov 2017 13:53:46 -0500

> media indicate spoken modality and language tags in text media indicate 

ISTM the real problem is with language tags in video media. These could 
indicate that the lip motions of people in the video reflect speakers of 
the tagged language. Or they could indicate written text in the 
specified language is embedded in the video. (Could be closed caption 
text or just signage.) Or (in the case of signed language tags) it could 
indicate use of sign language in the video.

But in the end, if this is declarative about what is being sent then it 
isn't clear whether it is important. If it is an indication of what is 
being requested, then it is more important.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Nov 2017 11:10:15 -0800

Paul said:

"ISTM the real problem is with language tags in video media. These could
indicate that the lip motions of people in the video reflect speakers of
the tagged language. Or they could indicate written text in the specified
language is embedded in the video. (Could be closed caption text or just
signage.) Or (in the case of signed language tags) it could indicate use of
sign language in the video.

But in the end, if this is declarative about what is being sent then it
isn't clear whether it is important. If it is an indication of what is
being requested, then it is more important."

[BA] Yes, that is the core of the problem.  As has been noted earlier, the
modality isn't indicated explicitly. I'm not sure whether we have enough
experience to know whether this represents an important deficit.  But we
could indicate that the problem potentially exists and that further work
might be needed.

On Mon, Nov 20, 2017 at 10:53 AM, Paul Kyzivat <[email-masked]>
wrote:

> the tagged language. Or they could indicate written text in the specified
> language is embedded in the video. (Could be closed caption text or just
> signage.) Or (in the case of signed language tags) it could indicate use of
> sign language in the video.
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 20 Nov 2017 14:19:59 -0500

We’re not chartered to solve a problem like “what kind of information is in a video: lip motion, sign language, captions?”
I think when you signal a sign language in a language tag, we all know what to expect.  If you put anything else in a video stream, we don’t know what to expect, and this working group isn’t chartered to fix that.

So, say that, and only that: “Use of a language selection in a video stream could have several meanings, including the use of sign language and visible captions.  If a sign language is signaled in a video stream, it is interpreted as the indicated sign language will appear in the video .  This document does not define any other use for language tags in video media.”

> On Nov 20, 2017, at 2:10 PM, Bernard Aboba <[email-masked]> wrote:
> 
> Paul said: 
> 
> "ISTM the real problem is with language tags in video media. These could indicate that the lip motions of people in the video reflect speakers of the tagged language. Or they could indicate written text in the specified language is embedded in the video. (Could be closed caption text or just signage.) Or (in the case of signed language tags) it could indicate use of sign language in the video.
> 
> But in the end, if this is declarative about what is being sent then it isn't clear whether it is important. If it is an indication of what is being requested, then it is more important."
> 
> [BA] Yes, that is the core of the problem.  As has been noted earlier, the modality isn't indicated explicitly. I'm not sure whether we have enough experience to know whether this represents an important deficit.  But we could indicate that the problem potentially exists and that further work might be needed.
> 
> On Mon, Nov 20, 2017 at 10:53 AM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
> [BA]  This is where the ground gets less solid - we don't really have a general mechanism for distinguishing spoken and written modality among non-signed languages. Perhaps we should just say "language tags in audio media indicate spoken modality and language tags in text media indicate written modality".
> 
> ISTM the real problem is with language tags in video media. These could indicate that the lip motions of people in the video reflect speakers of the tagged language. Or they could indicate written text in the specified language is embedded in the video. (Could be closed caption text or just signage.) Or (in the case of signed language tags) it could indicate use of sign language in the video.
> 
> But in the end, if this is declarative about what is being sent then it isn't clear whether it is important. If it is an indication of what is being requested, then it is more important.
> 
>         Thanks,
>         Paul
> 
> 
> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Nov 2017 15:04:44 -0500

On 11/20/17 2:10 PM, Bernard Aboba wrote:
> [BA] Yes, that is the core of the problem.  As has been noted earlier, 
> the modality isn't indicated explicitly. I'm not sure whether we have 
> enough experience to know whether this represents an important deficit.  
> But we could indicate that the problem potentially exists and that 
> further work might be needed.

Of these, I think we can declare the lip sync "modality" to be a 
non-issue. There is already a way to signal lip sync in SDP. If that is 
used, then the language tag on the audio can be inferred to apply as 
well to the linked video. That wouldn't cover a case where you can see 
moving lips but there is no corresponding audio, but that doesn't seem 
like a very important case to address.

I'd be happy to just leave it marked as for future work.

	Thanks,
	Paul

> On Mon, Nov 20, 2017 at 10:53 AM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>         [BA]  This is where the ground gets less solid - we don't really
>         have a general mechanism for distinguishing spoken and written
>         modality among non-signed languages. Perhaps we should just say
>         "language tags in audio media indicate spoken modality and
>         language tags in text media indicate written modality".
> 
> 
>     ISTM the real problem is with language tags in video media. These
>     could indicate that the lip motions of people in the video reflect
>     speakers of the tagged language. Or they could indicate written text
>     in the specified language is embedded in the video. (Could be closed
>     caption text or just signage.) Or (in the case of signed language
>     tags) it could indicate use of sign language in the video.
> 
>     But in the end, if this is declarative about what is being sent then
>     it isn't clear whether it is important. If it is an indication of
>     what is being requested, then it is more important.
> 
>              Thanks,
>              Paul
> 
>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 20 Nov 2017 21:44:47 +0100

> [BA] Is the "should" intended to be normative?
<GH>You are right that SHOULD should be avoided and it would be better 
to say MUST if we can. But I can imagine limited area applications 
having application agreements e.g. saying that a non-signed language tag 
in video media means a view of a talking person.   The negotiating 
applications know about this agreement so they can make the conclusion. 
So, if such situations can be included in how the parties make their 
conclusions, we can change to MUST.
> information about the modality: sign language tags in video media 
> indicate signed modality... A sign language can be identified by the 
> existence in the IANA registry of language subtags according to BCP 47 
> [RFC5646] of the language subtag with the Type field "extlang" 
> combined with the Prefix field value "sgn". A specific spoken or 
> written language can be identified by not having any such "sgn" Prefix.
>
> "application". Video media may be used for other modalities than 
> signed. Such use may be supported by further work or application 
> specific agreements or indications for evaluation of the intended 
> modality."
>
> spoken language tags for audio media indicate spoken modality and 
> written language tags for text media indicate written modality. The 
> examples in this specification are all from this set of three obvious 
> [BA]  This is where the ground gets less solid - we don't really have 
> a general mechanism for distinguishing spoken and written modality 
> among non-signed languages. Perhaps we should just say "language tags 
> in audio media indicate spoken modality and language tags in text 
> media indicate written modality".
Yes, right, that is better wording.

Gunnar
>
>
>
>
>
> On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellström 
>     It is not the signed languages that are causing the problem. It is
>     the spoken and written, when used in other media than the obvious
>     audio and text media.
>
>     And we should specify what is obvious and well defined and not, so
>     here is a new shorter proposal for section 5.4.
>
>     -----Old text----
>
>
>     stream, is not defined in this document. The problem of knowing
>     which language tags are signed and which are not is out of scope
>     of this document.
>
>     The combination of Language tags and other information in the
>     media descriptions should be composed so that the intended
>     modality can be concluded by the negotiating parties. The
>     following combinations of language tags and media provide obvious
>     information about the modality: sign language tags in video media
>     indicate signed modality, spoken language tags for audio media
>     indicate spoken modality and written language tags for text media
>     indicate written modality. The examples in this specification are
>     all from this set of three obvious language/media/modality
>     combinations.
>
>     A sign language can be identified by the existence in the IANA
>     registry of language subtags according to BCP 47 [RFC5646] of the
>     language subtag with the Type field "extlang" combined with the
>     Prefix field value "sgn".
>     A specific spoken or written language can be identified by not
>     having any such "sgn" Prefix.
>
>     "application". Video media may be used for other modalities than
>     signed. Such use may be supported by further work or application
>     specific agreements or indications for evaluation of the intended
>     modality.
>
>>>      "So let's delete Section 5.4 and be done with it.  Neither of
>>>     the statements is necessary."
>>>
>>>      "Non-signed" is not used outside of Section 5.4, so there would
>>>     not appear to be a need to define it if Section 5.4 were to be
>>>     deleted.
>>>
>>     Because the uses of the term are descriptive and mostly
>>     background, I do not think we need to add a definition or even a
>>     reference to a definition of the term.
>>
>>     --Randall
>>
>>>
>>>      If Gunnar's suggested definition can be confirmed,  this might
>>>     be as simple as adding a reference to the IANA language tag
>>>     repository.
>>>
>>>     <<mailto:[email-masked]>
>>>     <mailto:[email-masked]>[email-masked]
>>>     <mailto:[email-masked]>> wrote:
>>>
>>>     adding complexity rather than removing it.  I think the way
>>>     forward is to keep this document as simple as possible.  As
>>>     Bernard notes in his email of 10/23, there is no benefit in this
>>>     case of explicitly saying that certain things are not defined. 
>>>     Since the document does not define them, they are undefined in
>>>     the document.
>>>
>>>       In other words,it is not clear to me how Section 5.4's
>>>     discussion of scope improves or clarifies the situation in any
>>>     way - and there is some possibility that it could cause problems.
>>>
>>>
>>>
>>>      The comment from which #43 derives was made against a version
>>>     of the document that had text explicitly discussing signed
>>>     versus unsigned tags.  That text was subsequently deleted.
>>>
>>>      So, let's delete Section 5.4 and be done with it.  Neither of
>>>     the statements is necessary.
>>>
>>>      --
>>>      Randall Gellens
>     -- ----------------------------------------- Gunnar Hellström
>     Omnitor [email-masked]
>     <mailto:[email-masked]> +46 708 204 288
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 20 Nov 2017 22:03:57 +0100

Den 2017-11-20 kl. 21:04, skrev Paul Kyzivat:
>> "ISTM the real problem is with language tags in video media. These 
>> what is being requested, then it is more important."
>>
>> [BA] Yes, that is the core of the problem.  As has been noted 
>> earlier, the modality isn't indicated explicitly. I'm not sure 
>> whether we have enough experience to know whether this represents an 
>> important deficit.  But we could indicate that the problem 
>> potentially exists and that further work might be needed.
>
> non-issue. There is already a way to signal lip sync in SDP. If that 
> is used, then the language tag on the audio can be inferred to apply 
> as well to the linked video. That wouldn't cover a case where you can 
> see moving lips but there is no corresponding audio, but that doesn't 
> seem like a very important case to address.
>
<GH>Yes, further work, or application pre-agreement.

Gunnar
>
>     Thanks,
>     Paul
>
>> On Mon, Nov 20, 2017 at 10:53 AM, Paul Kyzivat 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 20 Nov 2017 22:14:03 +0100

A new proposal for new text taking in latest discussion of Bernard, Paul 
and Brian:

-----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 in this document. The problem of knowing which language tags 
are signed and which are not is out of scope of this document.

-----New text------------

The combination of Language tags and other information in the media 
descriptions shall be composed so that the intended modality can be 
concluded by the negotiating parties. The following combinations of 
language tags and media provide obvious information about the modality: 
sign language tags in video media indicate signed modality, language 
tags in audio media indicate spoken modality and language tags in text 
media indicate written modality. The examples in this specification are 
all from this set of three obvious language/media/modality combinations.

Use of language may appear in other media, such as "message" and 
"application". Video media may be used for other modalities than signed, 
e.g. a view of a speaker or text captions. Such use may be supported by 
further work or application specific agreements for evaluation of the 
intended modality.

---------------------------End of new 
text---------------------------------------

Den 2017-11-20 kl. 21:44, skrev Gunnar Hellström:
> having application agreements e.g. saying that a non-signed language 
> tag in video media means a view of a talking person.   The negotiating 
> applications know about this agreement so they can make the 
> conclusion. So, if such situations can be included in how the parties 
> make their conclusions, we can change to MUST.
>>
>> existence in the IANA registry of language subtags according to BCP 
>> 47 [RFC5646] of the language subtag with the Type field "extlang" 
>>     It is not the signed languages that are causing the problem. It
>>     is the spoken and written, when used in other media than the
>>     obvious audio and text media.
>>
>>     And we should specify what is obvious and well defined and not,
>>     so here is a new shorter proposal for section 5.4.
>>
>>     -----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 in this document. The problem of
>>     knowing which language tags are signed and which are not is out
>>     of scope of this document.
>>
>>>>      "Non-signed" is not used outside of Section 5.4, so there
>>>>     would not appear to be a need to define it if Section 5.4 were
>>>>     to be deleted.
>>>>
>>>>     Bernard notes in his email of 10/23, there is no benefit in
>>>>     this case of explicitly saying that certain things are not
>>>>     defined.  Since the document does not define them, they are
>>>>     undefined in the document.
>>>>
>>>>      I believe comment #43 should be closed as no longer
>>>>     applicable, since the text against which it was generated has
>>>>     been deleted. (I've said this before, and I believe it remains
>>>>     the case.)
>>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 20 Nov 2017 22:19:33 +0100

Den 2017-11-20 kl. 20:19, skrev Brian Rosen:

> We’re not chartered to solve a problem like “what kind of information 
> is in a video: lip motion, sign language, captions?”
> I think when you signal a sign language in a language tag, we all know 
> what to expect.  If you put anything else in a video stream, we don’t 
> know what to expect, and this working group isn’t chartered to fix that.
>
> So, say that, and only that: “Use of a language selection in a video 
> stream could have several meanings, including the use of sign language 
> and visible captions.  If a sign language is signaled in a video 
> stream, it is interpreted as the indicated sign language will appear 
> in the video .  This document does not define any other use for 
> language tags in video media.”
<GH>Yes, except for "WILL appear". It may still be just an indication of 
preference or capability and not yet sure that it will appear.
Anyway, I hope you find the wording in my latest just submitted proposal 
also suitable.

Gunnar
>
>
>> On Nov 20, 2017, at 2:10 PM, Bernard Aboba <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Paul said:
>>
>>         [BA]  This is where the ground gets less solid - we don't
>>         really have a general mechanism for distinguishing spoken and
>>         written modality among non-signed languages. Perhaps we
>>         should just say "language tags in audio media indicate spoken
>>         modality and language tags in text media indicate written
>>         modality".
>>
>>
>>     could indicate that the lip motions of people in the video
>>     reflect speakers of the tagged language. Or they could indicate
>>     written text in the specified language is embedded in the video.
>>     (Could be closed caption text or just signage.) Or (in the case
>>     of signed language tags) it could indicate use of sign language
>>     in the video.
>>
>>     But in the end, if this is declarative about what is being sent
>>     then it isn't clear whether it is important. If it is an
>>     indication of what is being requested, then it is more important.
>>
>>             Thanks,
>>             Paul
>>
>>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Nov 2017 14:16:58 -0800

Can we include text from Brian's suggestion? For example:

"If a sign language is signaled in a video stream, it is interpreted as an
indication that sign language will appear in the video.  A sign language
can be identified by the existence in the IANA registry of language subtags
according to BCP 47 [RFC5646] of the language subtag with the Type field
"extlang" combined with the Prefix field value "sgn".  A spoken/written
language tag can be identified by not having any such "sgn" prefix. This
document does not define any other use for language tags in video media
(such as how to indicate a desire for visible captions).

This document does not define the use of sign language tags in text or
audio media.  If a spoken/written language tag is included in text media,
it indicates a desire for written language. If a spoken/written language
tag is included in audio media, it is interpreted as an indication that
spoken language is desired.  Using the "lip sync" grouping mechanism
defined in [RFC5888], it is possible to indicate the desire to synchronize
audio and video so as to support lip reading.

Use of language tags may appear in other media, such as "message" and
"application".  Such use may be supported by further work or application
specific agreement."

On Mon, Nov 20, 2017 at 1:14 PM, Gunnar Hellström <
[email-masked]> wrote:

> sign language tags in video media indicate signed modality, language tags
> in audio media indicate spoken modality and language tags in text media
> indicate written modality. The examples in this specification are all from
> this set of three obvious language/media/modality combinations.
>
> ---------------------------End of new text---------------------------------------
>
>
>
> <GH>You are right that SHOULD should be avoided and it would be better to
> say MUST if we can. But I can imagine limited area applications having
> application agreements e.g. saying that a non-signed language tag in video
> media means a view of a talking person.   The negotiating applications know
> about this agreement so they can make the conclusion. So, if such
> situations can be included in how the parties make their conclusions, we
> can change to MUST.
>
>
> field value "sgn".  A specific spoken or written language can be
>>  On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens <
>> <mailto:[email-masked]> <[email-masked]>
>> [email-masked]> wrote:
>>
>> the text against which it was generated has been deleted. (I've said this

---

From: Randall Gellens <[email-masked]>
Date: Mon, 20 Nov 2017 16:44:19 -0800

At 1:53 PM -0500 11/20/17, Paul Kyzivat wrote:

> speakers of the tagged language. Or they could indicate written 
> text in the specified language is embedded in the video. (Could be 
> closed caption text or just signage.) Or (in the case of signed 
> language tags) it could indicate use of sign language in the video.

In the specific context of the draft, which is negotiating language 
and media for interactive real-time communications, I don't think 
signage or embedded written language makes sense.

> then it isn't clear whether it is important. If it is an indication 
> of what is being requested, then it is more important.

In an offer, it's a statement of what is acceptable.  In an answer, 
it's a statement of what was selected.

-------------- Randomly selected tag: ---------------
A real friend isn't someone you use once and throw away.  A real
friend is someone you can use again and again.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 20 Nov 2017 16:46:21 -0800

At 2:19 PM -0500 11/20/17, Brian Rosen wrote:

>  We're not chartered to solve a problem like "what kind of 
> information is in a video: lip motion, sign language, captions?"
>  I think when you signal a sign language in a language tag, we all 
> know what to expect.  If you put anything else in a video stream, 
> we don't know what to expect, and this working group isn't 
> chartered to fix that.
>
>  So, say that, and only that: "Use of a language selection in a 
> video stream could have several meanings, including the use of sign 
> language and visible captions.  If a sign language is signaled in a 
> video stream, it is interpreted as the indicated sign language will 
> appear in the video .  This document does not define any other use 
> for language tags in video media."

What about just not saying anything in this draft?  Keep this draft 
simple.  I don't think that we run an interoperability risk if we 
avoid saying what we're not defining.

-------------- Randomly selected tag: ---------------
Never call a man a fool.  Borrow from him.

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 21 Nov 2017 09:00:27 +0100

Den 2017-11-20 kl. 23:16, skrev Bernard Aboba:
> "If a sign language is signaled in a video stream, it is interpreted 
> as an indication that sign language will appear in the video. A sign 
> language can be identified by the existence in the IANA registry of 
> language subtags according to BCP 47 [RFC5646] of the language subtag 
> with the Type field "extlang" combined with the Prefix field value 
> "sgn". A spoken/written language tag can be identified by not having 
> any such "sgn" prefix. This document does not define any other use for 
> language tags in video media (such as how to indicate a desire for 
> visible captions).
>
> audio media. If a spoken/written language tag is included in text 
> media, it indicates a desire for written language. If a spoken/written 
> language tag is included in audio media, it is interpreted as an 
> indication that spoken language is desired.  Using the "lip sync" 
> grouping mechanism defined in [RFC5888], it is possible to indicate 
> the desire to synchronize audio and video so as to support lip reading.
>
> "application". Such use may be supported by further work or 
> application specific agreement."
<GH>Quite good. I see four small issues.
1: "WILL appear" is not right in the first sentence. The indication may 
be just one of a set of indicated languages.
2: The first paragraph says that we do not define other use of language 
tags in video than for sign language, but the second paragraph defines 
how to use tags for spoken language in video.
3: I prefer to start with the three normal clearly supported cases.
4: The indications sometimes indicate desire, sometimes capability. 
Therefore the word "desire" is not suitable in the explanations.
5: In the LC review, we had some resistance against using the term 
"spoken/written language tag". It appears again in the proposal. I do 
not understand the resistance and I do not know how strict it was, but 
we need to know if it is ok to use that term.  (I do not change that for 
now in the proposal below.)

A proposal trying to act on issues 1-4 plus other minor rewording:
  ---------------------------------------------------------------------------------------------------------------
5.4 Media, Language and Modality indications
A spoken/written language tag included in a text media description is an 
indication for written language. A spoken/written language tag included 
in an audio media description is an indication for spoken language. A 
sign language tag included in a video media description is an indication 
for sign language in the video stream.

A sign language can be identified by the existence in the IANA registry 
of language subtags according to BCP 47 [RFC5646] of the language subtag 
with the Type field "extlang" combined with the Prefix field value 
"sgn". A spoken/written language tag can be identified by not having any 
such "sgn" prefix.

This document does not define the use of sign language tags in text or 
audio media.  By including a language tag for spoken language in a video 
description and using the "lip sync" grouping mechanism defined in 
[RFC5888] it is possible to indicate synchronized audio and video so as 
to support lip reading. Other use of spoken/written language tags in a 
video description (such as for video embedded text captions) is not 
defined in this document.

Use of 'hlang' attributes may appear in other media descriptions, such 
as "message" and "application" supported by further work or application 
specific agreements.

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

>
>
>
> On Mon, Nov 20, 2017 at 1:14 PM, Gunnar Hellström 
>     A new proposal for new text taking in latest discussion of
>     Bernard, Paul and Brian:
>
>     -----Old text----
>
>
>     media descriptions shall be composed so that the intended modality
>     can be concluded by the negotiating parties. The following
>     combinations of language tags and media provide obvious
>     indicate signed modality, language tags in audio media indicate
>     spoken modality and language tags in text media indicate written
>     modality. The examples in this specification are all from this set
>     of three obvious language/media/modality combinations.
>
>     signed, e.g. a view of a speaker or text captions. Such use may be
>     supported by further work or application specific agreements for
>     evaluation of the intended modality.
>
>>>     modality can be concluded by the negotiating parties. "
>>>
>>     <GH>You are right that SHOULD should be avoided and it would be
>>     better to say MUST if we can. But I can imagine limited area
>>     applications having application agreements e.g. saying that a
>>     non-signed language tag in video media means a view of a talking
>>     person.   The negotiating applications know about this agreement
>>     so they can make the conclusion. So, if such situations can be
>>     included in how the parties make their conclusions, we can change
>>     to MUST.
>>>
>>>     The following combinations of language tags and media provide
>>>     obvious information about the modality: sign language tags in
>>>     video media indicate signed modality... A sign language can be
>>>     identified by the existence in the IANA registry of language
>>>     subtags according to BCP 47 [RFC5646] of the language subtag
>>>     with the Type field "extlang" combined with the Prefix field
>>>     value "sgn". A specific spoken or written language can be
>>>     specific agreements or indications for evaluation of the
>>>     intended modality."
>>>
>>>     spoken language tags for audio media indicate spoken modality
>>>     and written language tags for text media indicate written
>>>     modality. The examples in this specification are all from this
>>>     set of three obvious language/media/modality combinations.
>>>
>>>     <[email-masked]
>>>     <mailto:[email-masked]>> wrote:
>>>
>>>         It is not the signed languages that are causing the problem.
>>>         It is the spoken and written, when used in other media than
>>>         the obvious audio and text media.
>>>
>>>         And we should specify what is obvious and well defined and
>>>         not, so here is a new shorter proposal for section 5.4.
>>>
>>>         -----Old text----
>>>
>>>
>>>         video media stream, or a signed language tag for an audio or
>>>         text media stream, is not defined in this document. The
>>>         problem of knowing which language tags are signed and which
>>>         are not is out of scope of this document.
>>>
>>>         The combination of Language tags and other information in
>>>         the media descriptions should be composed so that the
>>>         intended modality can be concluded by the negotiating
>>>         parties. The following combinations of language tags and
>>>         media provide obvious information about the modality: sign
>>>         language tags in video media indicate signed modality,
>>>         spoken language tags for audio media indicate spoken
>>>         modality and written language tags for text media indicate
>>>         written modality. The examples in this specification are all
>>>         from this set of three obvious language/media/modality
>>>         combinations.
>>>
>>>         A sign language can be identified by the existence in the
>>>         IANA registry of language subtags according to BCP 47
>>>         [RFC5646] of the language subtag with the Type field
>>>         "extlang" combined with the Prefix field value "sgn".
>>>         A specific spoken or written language can be identified by
>>>         not having any such "sgn" Prefix.
>>>
>>>         Use of language may appear in other media, such as "message"
>>>         and "application". Video media may be used for other
>>>         modalities than signed. Such use may be supported by further
>>>         work or application specific agreements or indications for
>>>         evaluation of the intended modality.
>>>
>>>>>          "So let's delete Section 5.4 and be done with it. 
>>>>>         Neither of the statements is necessary."
>>>>>
>>>>>         would not appear to be a need to define it if Section 5.4
>>>>>         were to be deleted.
>>>>>
>>>>>          However, the term "signed" is used in 7 other places in
>>>>>         the document other than in Section 5.4.
>>>>
>>>>         background, I do not think we need to add a definition or
>>>>         even a reference to a definition of the term.
>>>>
>>>>         --Randall
>>>>
>>>>>
>>>>>          If Gunnar's suggested definition can be confirmed,  this
>>>>>         might be as simple as adding a reference to the IANA
>>>>>         language tag repository.
>>>>>
>>>>>          My view of issue #43 remains that we do not need to
>>>>>         specify a mechanism for determining which tags are
>>>>>         signed.  In the email discussion of the past month or so,
>>>>>         I fear we are drifting into adding complexity rather than
>>>>>         removing it.  I think the way forward is to keep this
>>>>>         document as simple as possible.  As Bernard notes in his
>>>>>         email of 10/23, there is no benefit in this case of
>>>>>         explicitly saying that certain things are not defined. 
>>>>>         Since the document does not define them, they are
>>>>>         discussion of scope improves or clarifies the situation in
>>>>>         any way - and there is some possibility that it could
>>>>>         cause problems.
>>>>>
>>>>>
>>>>>
>>>>>         applicable, since the text against which it was generated
>>>>>         has been deleted. (I've said this before, and I believe it
>>>>>         remains the case.)
>>>>>
>>>>>          The comment from which #43 derives was made against a
>>>>>         version of the document that had text explicitly
>>>>>         discussing signed versus unsigned tags.  That text was
>>>>>         subsequently deleted.
>>>>>
>>>>>          So, let's delete Section 5.4 and be done with it. 
>>>>>         Neither of the statements is necessary.
>>>>>
>>>>>          --
>>>>>          Randall Gellens
>>>         -- ----------------------------------------- Gunnar
>>>         Hellström Omnitor [email-masked]

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 21 Nov 2017 09:26:06 +0100

Den 2017-11-21 kl. 01:46, skrev Randall Gellens:

>> know what to expect.  If you put anything else in a video stream, we 
>> don't know what to expect, and this working group isn't chartered to 
>> fix that.
>>
>>  So, say that, and only that: "Use of a language selection in a video 
>> stream could have several meanings, including the use of sign 
<GH> I think it is good to specify the positive and simple cases, and 
also alert about that the use is not well defined for application and 
message media.
I think it is boiling down to a quite simple straightforward section 5.4 
now that we can agree to include.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Nov 2017 07:59:53 -0800

[BA] LGTM.  Do you recall what the objection was to the term
"spoken/written language"?

Gunnar had said:

"A proposal trying to act on issues 1-4 plus other minor rewording:
 -----------------------------------------------------------
----------------------------------------------------
5.4 Media, Language and Modality indications
A spoken/written language tag included in a text media description is an
indication for written language. A spoken/written language tag included in
an audio media description is an indication for spoken language. A sign
language tag included in a video media description is an indication for
sign language in the video stream.

A sign language can be identified by the existence in the IANA registry of
language subtags according to BCP 47 [RFC5646] of the language subtag with
the Type field "extlang" combined with the Prefix field value "sgn".  A
spoken/written language tag can be identified by not having any such "sgn"
prefix.

This document does not define the use of sign language tags in text or
audio media.  By including a language tag for spoken language in a video
description and using the "lip sync" grouping mechanism defined in
[RFC5888] it is possible to indicate synchronized audio and video so as to
support lip reading. Other use of spoken/written language tags in a video
description (such as for video embedded text captions) is not defined in
this document.

Use of 'hlang' attributes may appear in other media descriptions, such as
"message" and "application" supported by further work or application
specific agreements."

On Tue, Nov 21, 2017 at 12:00 AM, Gunnar Hellström <
[email-masked]> wrote:

> 1: "WILL appear" is not right in the first sentence. The indication may be
> just one of a set of indicated languages.
> tags in video than for sign language, but the second paragraph defines how
> to use tags for spoken language in video.
> "spoken/written language tag". It appears again in the proposal. I do not
> understand the resistance and I do not know how strict it was, but we need
> to know if it is ok to use that term.  (I do not change that for now in the
> proposal below.)
>
>
>  -----------------------------------------------------------
> ----------------------------------------------------
> the Type field "extlang" combined with the Prefix field value "sgn".  A
> spoken/written language tag can be identified by not having any such "sgn"
> prefix.
>
> [RFC5888] it is possible to indicate synchronized audio and video so as to
> support lip reading. Other use of spoken/written language tags in a video
> description (such as for video embedded text captions) is not defined in
> this document.
>
> Use of 'hlang' attributes may appear in other media descriptions, such as
> "message" and "application" supported by further work or application
> specific agreements.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Nov 2017 11:44:12 -0500

On 11/21/17 10:59 AM, Bernard Aboba wrote:
> By including a language tag for spoken language in a video 
> to support lip reading. 

When using lip sync, is there any necessity to put the language tag on 
the video? ISTM that is irrelevant, as long as it is on the synced audio 
media. ISTM it would be better to say:

    By including a language tag for spoken language in an audio
    description and using the "lip sync" grouping mechanism defined
    in [RFC5888] to group it with a video media stream it is possible
    to indicate synchronized audio and video so as to support lip
    reading.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Nov 2017 09:06:55 -0800

Paul said:

"When using lip sync, is there any necessity to put the language tag on the
video?"

[BA] Good point.

"   By including a language tag for spoken language in an audio
   description and using the "lip sync" grouping mechanism defined
   in [RFC5888] to group it with a video media stream it is possible
   to indicate synchronized audio and video so as to support lip
   reading."

[BA] This seems like an improvement.

On Tue, Nov 21, 2017 at 8:44 AM, Paul Kyzivat <[email-masked]> wrote:

>> By including a language tag for spoken language in a video description
>> and using the "lip sync" grouping mechanism defined in [RFC5888] it is
>> possible to indicate synchronized audio and video so as to support lip
>> reading.
>>
>
> When using lip sync, is there any necessity to put the language tag on the
> video? ISTM that is irrelevant, as long as it is on the synced audio media.
> ISTM it would be better to say:
>

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 21 Nov 2017 20:45:04 +0100

Den 2017-11-21 kl. 18:06, skrev Bernard Aboba:
> Paul said:
>
> "When using lip sync, is there any necessity to put the language tag 
> on the video?"
>
> [BA] Good point.
>
<GH>I do not think that an indication of lip reading synch grouping can 
be assumed to mean that the user promises to be seen in video. I guess 
that most products implementing the lip synch grouping do it generally 
for all calls regardless of if the user want to provide or see lips in 
synch. But it is a good feature to use if you desire to see a speaker.
The 'hlang' attribute in a video description is on the other hand clear 
indications that you want to provide or receive language in the video 
media stream.
Therefore I think we should return either to say that a spoken/written 
language tag in video media description means a view of the speaker if 
there is also a lip synch grouping, or even skip the dependency on lip 
synch grouping.  (there is a risk that we introduce tricky corner cases 
by the bundling of lip synch and language use. How about if we by 
further work agree on a way to indicate written captions in MPEG4 video, 
and want to indicate that in a product that always provides lip synch 
grouping. That will cause conflicts.)

Randall recently commented that use of text captions in the video stream 
is a far fetched use case. MPEG4 has caption elements defined and it can 
be provided in media declared as video, but it may be right that it is 
rarely or never used in conversational calls. If we can agree on that we 
could simply return to saying that a spoken/written language tag in 
video description means a view of a speaker, and skip the requirement to 
link it to the language in the audio stream.

Gunnar
>
> On Tue, Nov 21, 2017 at 8:44 AM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         description and using the "lip sync" grouping mechanism
>         defined in [RFC5888] it is possible to indicate synchronized
>     When using lip sync, is there any necessity to put the language
>     tag on the video? ISTM that is irrelevant, as long as it is on the
>     synced audio media. ISTM it would be better to say:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Nov 2017 15:53:58 -0500

On 11/21/17 2:45 PM, Gunnar Hellström wrote:
> synch.

I wonder if they do it even when it isn't true.

For instance, consider a movie that was created in English. So the 
actors are speaking English, the audio is labeled as English, and there 
is lip sync.

Now take the same movie and dub it in Spanish. Now the audio ought to be 
labeled as Spanish. But lip sync should no longer be indicated. Is that 
what happens in practice?

Of course, a totally deaf English speaking lip reader will understand 
both equally well. But there may not be anything in the signaling to 
indicate that he will have English lip motion.

The above isn't assuming that the content is being created explicitly to 
accommodate deaf people. If the goal is specifically to focus on that 
then some different policies might help.

	Thanks,
	Paul

> But it is a good feature to use if you desire to see a speaker.

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 21 Nov 2017 22:07:37 +0100

> "spoken/written language"?
<GH> It was in this mail in the archive:
https://www.ietf.org/mail-archive/web/slim/current/msg00744.html

It is Addison commenting on proposals for section 5.4, and specifically 
commenting on this proposed point:

>>>  2.    Text captions included in the video stream SHALL be indicated
>>> by a Language-Tag for spoken/written language.

<GH>And the comment from Addison was:

"I'm not sure what #2 really means. Shouldn't text captions be indicated by the written language
rather than the spoken language? And I'm not sure what "spoken/written language" means. "

<GH>My answer next day on this point was:

"
#2 was: "

2.    Text captions included in the video stream SHALL be indicated
by a Language-Tag for spoken/written language."

Yes, the intention is to use written language in the video stream. 
Thereare technologies for that.Since the language subtags in the IANA 
registry are combined for spokenlanguages and written languages, I call 
them Language-Tags forspoken/written language.It would be misleading to 
say that we use a Language-Tag for a writtenlanguage, because the same 
tag could in another context mean a spokenlanguage.Since we have the 
script subtag Zxxx for non-written, we do not need toconstruct an 
explicit tag for the written language tag, it should besufficient with 
our specification of the use in our case.In my latest recent proposal, I 
still have a very similar wording. Sinceyou had problems understanding 
it, there might still be a need to tuneit. Can you propose wording?This is the current
  proposal:

"   2.    Text captions included in the video stream SHOULD be indicated
   by a humintlang attribute with Language-Tag for spoken/written language.
"
<GH>Addison responded in https://www.ietf.org/mail-archive/web/slim/current/msg00757.html

> Yes, the intention is to use written language in the video stream. There are
> technologies for that.

I'm aware of that. My concern is that in this case "spoken/written" is applied to "text captions", which are not spoken be definition? This section is talking about the differences between identifying spoken and written language. The text captions fall into the written side of the equation, no?

I'd probably prefer to see something like
"2. Text captions included in the video stream SHOULD include a Language-Tag to identify the language."

> Since the language subtags in the IANA registry are combined for spoken
> languages and written languages, I call them Language-Tags for spoken/written
> language.

The language subtags are for languages--all modalities. My comment here
is that "spoken/written" adds no information.

> It would be misleading to say that we use a Language-Tag for a written
> language, because the same tag could in another context mean a spoken
> language.

One uses a Language-Tag for indicating the language. When the text is written,
sometimes the user will pick a different language tag (zh-Hant-HK) than they
might choose for spoken text (yue-HK, zh-cmn-HK, etc.). Sometimes (actually,
nearly all the time except for special cases) the language tag for the spoken
and written language is the same tag (en-US, de-CH, ja-JP, etc.). Again, the
modality of the language is a separate consideration from the language.
Nearly always, it is better to use the same tag for both spoken and written
content rather than trying to use the tag to distinguish between them:
different Content-Types require different decoders anyway, but it is really
useful to say "give me all of the 'en-US' content you have" or "do you have
  content for a user who speaks 'es'"

<GH> The result was that we modified text in a few places where we had used
"spoken/written language tag".

Now, the term has reappeared, and I assume that the language experts still
have the same concerns as in February.

When we use the term, it is intended to mean "tag for non-signed language".
Therefore it is not appropriate to just replace it with "Language tag"
and we need to decide what to do. Shall we define what we mean with
"spoken/written language tag" or try to reword the sentences containing that term?

Gunnar

> A spoken/written language tag included in a text media description is 
> an indication for written language. A spoken/written language tag 
> included in an audio media description is an indication for spoken 
> language. A sign language tag included in a video media description is 
> an indication for sign language in the video stream.
>
> field value "sgn". A spoken/written language tag can be identified by 
> not having any such "sgn" prefix.
>
> audio media.  By including a language tag for spoken language in a 
> video description and using the "lip sync" grouping mechanism defined 
> in [RFC5888] it is possible to indicate synchronized audio and video 
> so as to support lip reading. Other use of spoken/written language 
> tags in a video description (such as for video embedded text captions) 
> is not defined in this document.
>
> as "message" and "application" supported by further work or 
> application specific agreements."
>
> On Tue, Nov 21, 2017 at 12:00 AM, Gunnar Hellström 
>>     "If a sign language is signaled in a video stream, it is
>>     interpreted as an indication that sign language will appear in
>>     the video. A sign language can be identified by the existence in
>>     the IANA registry of language subtags according to BCP 47
>>     combined with the Prefix field value "sgn". A spoken/written
>>     language tag can be identified by not having any such "sgn"
>>     prefix. This document does not define any other use for language
>>     tags in video media (such as how to indicate a desire for visible
>>     captions).
>>
>>     This document does not define the use of sign language tags in
>>     text or audio media. If a spoken/written language tag is included
>>     in text media, it indicates a desire for written language. If a
>>     spoken/written language tag is included in audio media, it is
>>     interpreted as an indication that spoken language is desired. 
>>     Using the "lip sync" grouping mechanism defined in [RFC5888], it
>>     is possible to indicate the desire to synchronize audio and video
>>     so as to support lip reading.
>>
>>     Use of language tags may appear in other media, such as "message"
>>     and "application".  Such use may be supported by further work or
>     1: "WILL appear" is not right in the first sentence. The
>     indication may be just one of a set of indicated languages.
>     2: The first paragraph says that we do not define other use of
>     language tags in video than for sign language, but the second
>     paragraph defines how to use tags for spoken language in video.
>     4: The indications sometimes indicate desire, sometimes
>     capability. Therefore the word "desire" is not suitable in the
>     explanations.
>     "spoken/written language tag". It appears again in the proposal. I
>     do not understand the resistance and I do not know how strict it
>     was, but we need to know if it is ok to use that term.  (I do not
>     change that for now in the proposal below.)
>
>
>     A spoken/written language tag included in a text media description
>     is an indication for written language. A spoken/written language
>     tag included in an audio media description is an indication for
>     spoken language. A sign language tag included in a video media
>     description is an indication for sign language in the video stream.
>
>     Prefix field value "sgn". A spoken/written language tag can be
>     identified by not having any such "sgn" prefix.
>
>     This document does not define the use of sign language tags in
>     text or audio media.  By including a language tag for spoken
>     language in a video description and using the "lip sync" grouping
>     mechanism defined in [RFC5888] it is possible to indicate
>     synchronized audio and video so as to support lip reading. Other
>     use of spoken/written language tags in a video description (such
>     as for video embedded text captions) is not defined in this document.
>
>     Use of 'hlang' attributes may appear in other media descriptions,
>     such as "message" and "application" supported by further work or
>     application specific agreements.
>
>>         media descriptions shall be composed so that the intended
>>         following combinations of language tags and media provide
>>         video media indicate signed modality, language tags in audio
>>         media indicate spoken modality and language tags in text
>>         media indicate written modality. The examples in this
>>         specification are all from this set of three obvious
>>         modalities than signed, e.g. a view of a speaker or text
>>         captions. Such use may be supported by further work or
>>         application specific agreements for evaluation of the
>>         intended modality.
>>
>>>>         parties. "
>>>         <GH>You are right that SHOULD should be avoided and it would
>>>         be better to say MUST if we can. But I can imagine limited
>>>         area applications having application agreements e.g. saying
>>>         that a non-signed language tag in video media means a view
>>>         of a talking person.   The negotiating applications know
>>>         about this agreement so they can make the conclusion. So, if
>>>         such situations can be included in how the parties make
>>>         their conclusions, we can change to MUST.
>>>>
>>>>         The following combinations of language tags and media
>>>>         provide obvious information about the modality: sign
>>>>         language tags in video media indicate signed modality... A
>>>>         sign language can be identified by the existence in the
>>>>         "extlang" combined with the Prefix field value "sgn". A
>>>>         specific spoken or written language can be identified by
>>>>         Use of language may appear in other media, such as
>>>>         "message" and "application". Video media may be used for
>>>>         other modalities than signed. Such use may be supported by
>>>>         further work or application specific agreements or
>>>>         indications for evaluation of the intended modality."
>>>>
>>>>         written modality. The examples in this specification are
>>>>         really have a general mechanism for distinguishing spoken
>>>>         and written modality among non-signed languages. Perhaps we
>>>>         should just say "language tags in audio media indicate
>>>>         spoken modality and language tags in text media indicate
>>>>         written modality".
>>>>             It is not the signed languages that are causing the
>>>>             problem. It is the spoken and written, when used in
>>>>             other media than the obvious audio and text media.
>>>>
>>>>             And we should specify what is obvious and well defined
>>>>             and not, so here is a new shorter proposal for section 5.4.
>>>>
>>>>             -----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 in this
>>>>             document. The problem of knowing which language tags
>>>>             The combination of Language tags and other information
>>>>             in the media descriptions should be composed so that
>>>>             the intended modality can be concluded by the
>>>>             negotiating parties. The following combinations of
>>>>             language tags and media provide obvious information
>>>>             about the modality: sign language tags in video media
>>>>             indicate signed modality, spoken language tags for
>>>>             audio media indicate spoken modality and written
>>>>             language tags for text media indicate written modality.
>>>>             The examples in this specification are all from this
>>>>             A sign language can be identified by the existence in
>>>>             the IANA registry of language subtags according to BCP
>>>>             47 [RFC5646] of the language subtag with the Type field
>>>>             A specific spoken or written language can be identified
>>>>             Use of language may appear in other media, such as
>>>>             "message" and "application". Video media may be used
>>>>             for other modalities than signed. Such use may be
>>>>             supported by further work or application specific
>>>>>>              "Non-signed" is not used outside of Section 5.4, so
>>>>>>             there would not appear to be a need to define it if
>>>>>>             Section 5.4 were to be deleted.
>>>>>>
>>>>>>              However, the term "signed" is used in 7 other places
>>>>>>             in the document other than in Section 5.4.
>>>>>
>>>>>             Because the uses of the term are descriptive and
>>>>>             mostly background, I do not think we need to add a
>>>>>             definition or even a reference to a definition of the
>>>>>             term.
>>>>>
>>>>>             --Randall
>>>>>
>>>>>>
>>>>>>              If Gunnar's suggested definition can be confirmed,
>>>>>>             this might be as simple as adding a reference to the
>>>>>>             IANA language tag repository.
>>>>>>
>>>>>>             signed.  In the email discussion of the past month or
>>>>>>             so, I fear we are drifting into adding complexity
>>>>>>             rather than removing it.  I think the way forward is
>>>>>>             to keep this document as simple as possible. As
>>>>>>             Bernard notes in his email of 10/23, there is no
>>>>>>             benefit in this case of explicitly saying that
>>>>>>             certain things are not defined. Since the document
>>>>>>             does not define them, they are undefined in the
>>>>>>             document.
>>>>>>
>>>>>>               In other words,it is not clear to me how Section
>>>>>>             5.4's discussion of scope improves or clarifies the
>>>>>>             situation in any way - and there is some possibility
>>>>>>             that it could cause problems.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             applicable, since the text against which it was
>>>>>>             generated has been deleted. (I've said this before,
>>>>>>             and I believe it remains the case.)
>>>>>>
>>>>>>              The comment from which #43 derives was made against
>>>>>>             a version of the document that had text explicitly
>>>>>>             discussing signed versus unsigned tags.  That text
>>>>>>             was subsequently deleted.
>>>>>>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 21 Nov 2017 13:54:16 -0800

At 3:53 PM -0500 11/21/17, Paul Kyzivat wrote:

> actors are speaking English, the audio is labeled as English, and 
> there is lip sync.
>
>  Now take the same movie and dub it in Spanish. Now the audio ought 
> to be labeled as Spanish. But lip sync should no longer be 
> indicated. Is that what happens in practice?
>
>  Of course, a totally deaf English speaking lip reader will 
> understand both equally well. But there may not be anything in the 
> signaling to indicate that he will have English lip motion.
>
>  The above isn't assuming that the content is being created 
> explicitly to accommodate deaf people. If the goal is specifically 
> to focus on that then some different policies might help.

Since the context of the draft is interactive real-time media, and 
since we want to keep the draft as simple as possible, we're probably 
better off not getting into lip sync.  We can just avoid mention, and 
it can be added in later work.

-------------- Randomly selected tag: ---------------
Hospitals are Sued by 7 Foot Doctors
--Newspaper headline

---

From: Randall Gellens <[email-masked]>
Date: Tue, 21 Nov 2017 14:01:47 -0800

I noticed that in the reply that Gunnar copied, 
Addison says "it is really useful to say "give me 
all of the 'en-US' content you have" or "do you 
have content for a user who speaks 'es' ".  Such 
uses are outside the scope of the document.  I 
also note that the comment was against wording 
that has since been deleted.

--Randall

At 10:07 PM +0100 11/21/17, Gunnar Hellström wrote:

>>  [BA] LGTM.  Do you recall what the objection 
>> was to the term "spoken/written language"?
>>
> <https://www.ietf.org/mail-archive/web/slim/current/msg00744.html>https://www.ietf.org/mail-archive/web/slim/current/msg00744.html
>
>  It is Addison commenting on proposals for 
> section 5.4, and specifically commenting on 
> this proposed point:
>
>  "I'm not sure what #2 really means. Shouldn't 
> text captions be indicated by the written 
> language
>  rather than the spoken language? And I'm not 
> sure what "spoken/written language" means. "
>
>  Yes, the intention is to use written language 
> in the video stream. There are technologies for 
> that. Since the language subtags in the IANA 
> registry are combined for spoken languages and 
> written languages, I call them Language-Tags 
> for spoken/written language. It would be 
> misleading to say that we use a Language-Tag 
> for a writtenlanguage, because the same tag 
> could in another context mean a 
> spoken language. Since we have the script 
> subtag Zxxx for non-written, we do not need 
> to construct an explicit tag for the written 
> language tag, it should be sufficient with our 
> specification of the use in our case.In my 
> latest recent proposal, I still have a very 
> similar wording. Since you had problems 
> understanding it, there might still be a need 
> to tune it. Can you propose wording?This is the 
> current
>   proposal:
>
>  <GH>Addison responded in 
> <https://www.ietf.org/mail-archive/web/slim/current/msg00757.html>https://www.ietf.org/mail-archive/web/slim/current/msg00757.html
>
>  I'm aware of that. My concern is that in this 
> case "spoken/written" is applied to "text 
> captions", which are not spoken be definition? 
> This section is talking about the differences 
> between identifying spoken and written 
> language. The text captions fall into the 
> written side of the equation, no?
>
>  "2. Text captions included in the video stream 
> SHOULD include a Language-Tag to identify the 
> language."
>
>>  A spoken/written language tag included in a 
>> text media description is an indication for 
>> written language. A spoken/written language 
>> tag included in an audio media description is 
>> an indication for spoken language. A sign 
>> language tag included in a video media 
>> combined with the Prefix field value "sgn".  A 
>> spoken/written language tag can be identified 
>> by not having any such "sgn" prefix.
>>
>>  This document does not define the use of sign 
>> language tags in text or audio media.  By 
>> including a language tag for spoken language 
>> in a video description and using the "lip 
>> sync" grouping mechanism defined in [RFC5888] 
>> it is possible to indicate synchronized audio 
>> and video so as to support lip reading. Other 
>> use of spoken/written language tags in a video 
>> description (such as for video embedded text 
>> captions) is not defined in this document.
>>
>>
>>  Use of 'hlang' attributes may appear in other 
>> media descriptions, such as "message" and 
>> "application" supported by further work or 
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>  "If a sign language is signaled in a video 
>> stream, it is interpreted as an indication 
>> that sign language will appear in the 
>> video.  A sign language can be identified by 
>> the existence in the IANA registry of language 
>> combined with the Prefix field value "sgn".  A 
>> spoken/written language tag can be identified 
>> by not having any such "sgn" prefix. This 
>> document does not define any other use for 
>> language tags in video media (such as how to 
>> indicate a desire for visible captions).
>>
>>  This document does not define the use of sign 
>> language tags in text or audio media.  If a 
>> spoken/written language tag is included in 
>> text media, it indicates a desire for written 
>> language. If a spoken/written language tag is 
>> included in audio media, it is interpreted as 
>> an indication that spoken language is desired. 
>> Using the "lip sync" grouping mechanism 
>> defined in [RFC5888], it is possible to 
>> indicate the desire to synchronize audio and 
>> video so as to support lip reading.
>>
>>  Use of language tags may appear in other 
>> media, such as "message" and "application". 
>> Such use may be supported by further work or 
>>  1: "WILL appear" is not right in the first 
>> sentence. The indication may be just one of a 
>> set of indicated languages.
>>  2: The first paragraph says that we do not 
>> define other use of language tags in video 
>> than for sign language, but the second 
>>  4: The indications sometimes indicate desire, 
>> sometimes capability. Therefore the word 
>> "desire" is not suitable in the explanations.
>>  5: In the LC review, we had some resistance 
>> against using the term "spoken/written 
>> language tag". It appears again in the 
>> proposal. I do not understand the resistance 
>> and I do not know how strict it was, but we 
>> need to know if it is ok to use that term.  (I 
>> do not change that for now in the proposal 
>> below.)
>>
>>
>>  A spoken/written language tag included in a 
>> text media description is an indication for 
>> written language. A spoken/written language 
>> tag included in an audio media description is 
>> an indication for spoken language. A sign 
>> language tag included in a video media 
>> combined with the Prefix field value "sgn".  A 
>> spoken/written language tag can be identified 
>> by not having any such "sgn" prefix.
>>
>>  This document does not define the use of sign 
>> language tags in text or audio media.  By 
>> including a language tag for spoken language 
>> in a video description and using the "lip 
>> sync" grouping mechanism defined in [RFC5888] 
>> it is possible to indicate synchronized audio 
>> and video so as to support lip reading. Other 
>> use of spoken/written language tags in a video 
>> description (such as for video embedded text 
>> captions) is not defined in this document.
>>
>>
>>  Use of 'hlang' attributes may appear in other 
>> media descriptions, such as "message" and 
>> "application" supported by further work or 
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>  A new proposal for new text taking in latest 
>> discussion of Bernard, Paul and Brian:
>>
>>  -----Old text----
>>
>> information in the media descriptions shall be 
>> indicate signed modality, language tags in 
>> audio media indicate spoken modality and 
>> language tags in text media indicate written 
>> modality. The examples in this specification 
>>  Use of language may appear in other media, 
>> such as "message" and "application". Video 
>> media may be used for other modalities than 
>> signed, e.g. a view of a speaker or text 
>> captions. Such use may be supported by further 
>> work or application specific agreements for 
>>> information in the media descriptions should 
>>> be composed so that the intended modality can 
>>> be concluded by the negotiating parties. "
>>>
>>  <GH>You are right that SHOULD should be 
>> avoided and it would be better to say MUST if 
>> we can. But I can imagine limited area 
>> applications having application agreements 
>> e.g. saying that a non-signed language tag in 
>> video media means a view of a talking person. 
>> The negotiating applications know about this 
>> agreement so they can make the conclusion. So, 
>> if such situations can be included in how the 
>> parties make their conclusions, we can change 
>> to MUST. 
>>
>>>
>>  The following combinations of language tags 
>> and media provide obvious information about 
>> the modality: sign language tags in video 
>> media indicate signed modality... A sign 
>> language can be identified by the existence in 
>> the IANA registry of language subtags 
>> according to BCP 47 [RFC5646] of the language 
>> subtag with the Type field "extlang" combined 
>> with the Prefix field value "sgn".  A specific 
>> spoken or written language can be identified 
>>  Use of language may appear in other media, 
>> such as "message" and "application". Video 
>> media may be used for other modalities than 
>> signed. Such use may be supported by further 
>> work or application specific agreements or 
>> indications for evaluation of the intended 
>> modality. "
>>
>>
>>  [BA] Assume we can confirm the mechanism for 
>> distinguishing signed/non-signed languages, 
>> this part seems relatively solid.
>>
>>  spoken language tags for audio media indicate 
>> spoken modality and written language tags for 
>> text media indicate written modality. The 
>>  [BA]  This is where the ground gets less solid 
>> - we don't really have a general mechanism for 
>> distinguishing spoken and written modality 
>> among non-signed languages. Perhaps we should 
>> just say "language tags in audio media 
>> indicate spoken modality and language tags in 
>> text media indicate written modality".
>>
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>  It is not the signed languages that are 
>> causing the problem. It is the spoken and 
>> written, when used in other media than the 
>> information in the media descriptions should 
>> be composed so that the intended modality can 
>> be concluded by the negotiating parties. The 
>>  Use of language may appear in other media, 
>> such as "message" and "application". Video 
>> media may be used for other modalities than 
>> signed. Such use may be supported by further 
>> work or application specific agreements or 
>> indications for evaluation of the intended 
>> modality.
>>
>> 
>>>>   "So let's delete Section 5.4 and be done 
>>>> with it.  Neither of the statements is 
>>>> necessary."
>>>>
>>>>   However, the term "signed" is used in 7 
>>>> other places in the document other than in 
>>>> Section 5.4.
>>>>
>>
>>>   So, let's delete Section 5.4 and be done 
>>> with it.  Neither of the statements is 
>>> necessary.
>>>
>>>   --
>>>   Randall Gellens
>>  <mailto:[email-masked]>[email-masked]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>
>>
>>  --

-------------- Randomly selected tag: ---------------
Premature optimization is the root of all evil
                              --C. A. R. Hoare

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 21 Nov 2017 23:05:39 +0100

Den 2017-11-21 kl. 21:53, skrev Paul Kyzivat:
>> <GH>I do not think that an indication of lip reading synch grouping 
>> can be assumed to mean that the user promises to be seen in video. I 
>> guess that most products implementing the lip synch grouping do it 
>> generally for all calls regardless of if the user want to provide or 
>> see lips in synch.
>
<GH> The purpose of our protocol is to be used for conversational 
services. i.e. real-time calls. And for them, I just assume that if the 
manufacturer of the device has taken the effort to implement RFC 5888 
Lip Sync, it is a technical feature that is active in all calls of the 
device regardless of how the users intend to use the media. All users 
appreciate good sync, so if the device is capable of providing good sync 
without sacrificing other factors too much, it will be used.
It is not really realistic to turn Lip Sync on or off depending on the 
language preference settings.

> Now take the same movie and dub it in Spanish. Now the audio ought to 
> be labeled as Spanish. But lip sync should no longer be indicated. Is 
> that what happens in practice?
<GH>The example is from streamed application. I think lip sync will be 
activated anyway if the streaming service supports it. RFC 5888 is not 
meant to just handle the real lip sync usage, it is to indicate when 
good sync can be supported technically. RFC 5888 says: "Note that LS 
semantics apply not only to a video stream that has to be synchronized 
with an audio stream; the playout of two streams of the same type can be 
synchronized as well." That clearly indicates that it is not intended 
for just the lip sync use.
> indicate that he will have English lip motion.
<GH>Right, that is a good reason for keeping the spoken language tag in 
the video description, and not requiring the same language to appear in 
the audio media description.

So, as a summary, I am afraid that the good idea of using RFC 5888 Lip 
Sync as an indication that we mean a view of a speaking person in video 
has similar bad side effects as my cancelled proposal to use the 
"speaker" in an SDP Content attribute according to RFC 4796 [RFC4796] 
for the same purpose. What is left to do for now is to not define any 
way to indicate language of captions in the video stream but use 
spoken/written language tags in video as an indication to view a 
speaker. This is also supported by Randalls observation that captions in 
video is hardly used in conversational calls.

I will create a new 5.4 proposal in another mail.

Gunnar

>
> The above isn't assuming that the content is being created explicitly 
> to accommodate deaf people. If the goal is specifically to focus on 
> that then some different policies might help.

>> The 'hlang' attribute in a video description is on the other hand 
>> clear indications that you want to provide or receive language in the 
>> video media stream.
>> Therefore I think we should return either to say that a 
>> spoken/written language tag in video media description means a view 
>> of the speaker if there is also a lip synch grouping, or even skip 
>> the dependency on lip synch grouping.  (there is a risk that we 
>> introduce tricky corner cases by the bundling of lip synch and 
>> language use. How about if we by further work agree on a way to 
>> indicate written captions in MPEG4 video, and want to indicate that 
>> in a product that always provides lip synch grouping. That will cause 
>> conflicts.)
>>
>> Randall recently commented that use of text captions in the video 
>> stream is a far fetched use case. MPEG4 has caption elements defined 
>> and it can be provided in media declared as video, but it may be 
>> right that it is rarely or never used in conversational calls. If we 
>> can agree on that we could simply return to saying that a 
>> spoken/written language tag in video description means a view of a 
>> speaker, and skip the requirement to link it to the language in the 
>> audio stream.
>>
>> Gunnar
>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 21 Nov 2017 23:50:15 +0100

Den 2017-11-21 kl. 23:08, skrev Randall Gellens:
> Based on the text and comments from Gunnar, brian, Paul, and Bernard, 
> here is what I propose to replace section 5.4 with:
>
> 5.4.  Usage Notes
>
>    A sign language tag with a video stream is interpreted as an
>    indication for sign language in the video stream.  A non-sign
>    language tag with text media is interpreted as an indication for
>    written language.  A non-sign language tag with audio media is
>    interpreted as an indication for spoken language.
>
>    In the IANA registry of language subtags per BCP 47 [RFC5646], a
>    language subtag with a Type field "extlang" combined with a Prefix
>    field value "sgn" indicates a sign language tag.  The absense of
>    such "sgn" prefix indicates a non-sign language tag.  This document
>    does not define any other use for language tags in video media
>    (such as how to indicate visible captions).
>
>    This document does not define the use of sign language tags in text
>    or audio media.
>
>    This document does not define the use of language tags in media
>    other than interactive streams of audio, video, and text (such as
>    "message" or "application").
<GH> Good, I hope that "non-sign language" can be an accepted term.
I provide a slightly modified 5.4 proposal, with a bit more consistent 
language in the first paragraph, and the mentioning of further work or 
application agreement reinserted. I think that is better than just 
saying that it is not defined. I also added the spoken language in video 
is a view of a speaker according to recent discussion in another mail.
I really hope to find that we are converging now.

------------------------------new text 
-------------------------------------------
5.4 Media, Language and Modality indications

    A sign language tag with video media is interpreted as an
    indication for sign language in the video stream.  A non-sign
    language tag with text media is interpreted as an indication for
    written language.  A non-sign language tag with audio media is
    interpreted as an indication for spoken language. A non-sign
   language tag with video media is interpreted as a view of a
   speaking person. This document does not define any other
   use for language tags in video media (such as how to indicate
   visible captions in the video stream).

    In the IANA registry of language subtags per BCP 47 [RFC5646], a
    language subtag with a Type field "extlang" combined with a Prefix
    field value "sgn" indicates a sign language tag.  The absense of
    such "sgn" prefix indicates a non-sign language tag.

    This document does not define the use of sign language tags in text
    or audio media. This document does not define the use of language 
tags in media
    other than interactive streams of audio, video, and text (such as
    "message" or "application"). Such use may be supported by further work
    or application specific agreements.

---------------------------------------------------------------------------------------------
Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Tue, 21 Nov 2017 14:08:43 -0800

5.4.  Usage Notes

-------------- Randomly selected tag: ---------------
In the United States the majority undertakes to supply a multitude of
ready-made opinions for the use of individuals, who are thus relieved
from the necessity of forming opinions of their own
      --Alexis de Tocqueville

---

From: Randall Gellens <[email-masked]>
Date: Tue, 21 Nov 2017 15:17:30 -0800

I agree.  I made a few minor editorial changes 
(e.g., moving some text to a new paragraph):

5.4.  Usage Notes

    A sign language tag with a video media stream is interpreted as an
    indication for sign language in the video stream.  A non-sign
    language tag with a text media stream is interpreted as an
    indication for written language in the text stream.  A non-sign
    language tag with an audio media stream is interpreted as an
    indication for spoken language in the audio stream.

    This document does not define any other use for language tags in
    video media (such as how to indicate visible captions in the video
    stream).

    This document does not define the use of language tags in media
    other than interactive streams of audio, video, and text (such as
    "message" or "application").  Such use could be supported by future
    work or by application agreement.

At 11:50 PM +0100 11/21/17, Gunnar Hellström wrote:

>>  Based on the text and comments from Gunnar, 
>> brian, Paul, and Bernard, here is what I 
>> propose to replace section 5.4 with:
>>
>>  5.4. Usage Notes
>>
>  I provide a slightly modified 5.4 proposal, 
> with a bit more consistent language in the 
> first paragraph, and the mentioning of further 
> work or application agreement reinserted. I 
> think that is better than just saying that it 
> is not defined. I also added the spoken 
> language in video is a view of a speaker 
> according to recent discussion in another mail.
>  or audio media. This document does not define 
> the use of language tags in media

-------------- Randomly selected tag: ---------------
Never knock the way the other cat swings.
                          --Neal Cassady

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Nov 2017 16:19:53 -0800

Randall said:

"Since the context of the draft is interactive real-time media, and since
we want to keep the draft as simple as possible, we're probably better off
not getting into lip sync.  We can just avoid mention, and it can be added
in later work."

[BA] RFC 5888 already defines how to handle lip sync negotiation in SDP.  I
think Paul's point was that that document is sufficient so that referring
to a need for "later work" is misleading.

On Tue, Nov 21, 2017 at 1:54 PM, Randall Gellens <[email-masked]>
wrote:

>> actors are speaking English, the audio is labeled as English, and there is
>> lip sync.
>>
>> accommodate deaf people. If the goal is specifically to focus on that then
>> some different policies might help.
>>
>
> Since the context of the draft is interactive real-time media, and since
> we want to keep the draft as simple as possible, we're probably better off
> not getting into lip sync.  We can just avoid mention, and it can be added
> in later work.
>
> --
> Randall Gellens

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Nov 2017 18:17:30 -0800

Looks good to me.

On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens <[email-masked]>
wrote:

> I agree.  I made a few minor editorial changes (e.g., moving some text to
> a new paragraph):
>
> 5.4.  Usage Notes
>
>> application agreement reinserted. I think that is better than just saying
>> that it is not defined. I also added the spoken language in video is a view
>> of a speaker according to recent discussion in another mail.
>>  ------------------------------new text ------------------------------
>> -------------
>>  or audio media. This document does not define the use of language tags
>> in media

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 22 Nov 2017 14:48:27 +0900

> A specific spoken or written language can be identified by not having 

https://tools.ietf.org/html/rfc5646#section-3.4, point 12.C.3, currently 
says:

             3.  Sign languages SHOULD have an 'extlang' record with a
                 'Prefix' of 'sgn'.

As everybody here on this list knows, a SHOULD is not a guarantee, 
because there might be exceptions. The fact that there currently are no 
exceptions doesn't guarantee that there will be no exceptions in the future.

Regards,   Martin.

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 22 Nov 2017 07:29:14 +0100

Den 2017-11-22 kl. 06:48, skrev Martin J. Dürst:
>> A new proposal for new text taking in latest discussion of Bernard, 
>> Paul and Brian:
>
> https://tools.ietf.org/html/rfc5646#section-3.4, point 12.C.3, 
> currently says:
>
> because there might be exceptions. The fact that there currently are 
> no exceptions doesn't guarantee that there will be no exceptions in 
> the future.
<GH>Right, but a new registration of a sign language in the future 
without registering the 'sgn' Prefix for it will risk to cause interop 
problems for that language, so that should not continuously be done. And 
if it is done, it should be corrected. And while it is in the process of 
being amended in the language registry, applications supporting that 
language could regard it to be a sign language anyway by application 
agreement.
So, I think we can live with it.

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 22 Nov 2017 07:53:48 +0100

Randall,

1. You dropped one sentence from the first paragraph in my latest proposal:

"A non-sign language tag with video media is interpreted as a view of a
  speaking person."

It was a result of the previous discussion and reasoning, and I think it 
should be reinserted.

2. You also changed the title proposal from " 5.4 Media, Language and 
Modality indications" to "5.4 Usage Notes"

I think it is better to have a title that tells about the topic of the 
paragraph. I suggest to use the title I proposed, but I can accept yours 
if you have a good reason for the change.

Thanks,

Gunnar

Den 2017-11-22 kl. 03:17, skrev Bernard Aboba:
> Looks good to me.
>
> On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I agree. I made a few minor editorial changes (e.g., moving some
>     text to a new paragraph):
>
>     5.4.  Usage Notes
>
>              Based on the text and comments from Gunnar, brian, Paul,
>             and Bernard, here is what I propose to replace section 5.4
>             with:
>
>              5.4. Usage Notes
>
>          I provide a slightly modified 5.4 proposal, with a bit more
>         consistent language in the first paragraph, and the mentioning
>         of further work or application agreement reinserted. I think
>         that is better than just saying that it is not defined. I also
>         added the spoken language in video is a view of a speaker
>          or audio media. This document does not define the use of
>         language tags in media
>          <mailto:[email-masked]
>         <mailto:[email-masked]>>[email-masked]
>         <mailto:[email-masked]>
>         +46 708 204 288 <tel:%2B46%20708%20204%20288>
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Nov 2017 23:17:18 -0800

Gunnar said:

"A non-sign language tag with video media is interpreted as a view of
a speaking
person"

[BA] I believe that Paul pointed out that such a need can be met by asking
for audio with the non-sign language tag and RFC 5888 lip sync grouping,
with no language tag for the video.

On Tue, Nov 21, 2017 at 10:53 PM, Gunnar Hellström <
[email-masked]> wrote:

> paragraph. I suggest to use the title I proposed, but I can accept yours if
> you have a good reason for the change.
>
> Thanks,
>
> Gunnar
>
> On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens <

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 22 Nov 2017 17:03:41 +0100

Den 2017-11-22 kl. 08:17, skrev Bernard Aboba:
> a speaking person"
> [BA] I believe that Paul pointed out that such a need can be met by 
> asking for audio with the non-sign language tag and RFC 5888 lip sync 
> grouping, with no language tag for the video.
<GH>But I explained  in later mail that the LipSync grouping is a 
technical mechanism that is not expected to be set and unset depending 
on users desire to use lip reading or not. It will likely be always 
active for products using that feature for providing good sync 
regardless of what the users plan to use the video for. So, it is not 
what we want.

What we want is an indication that the user is prepared / desires to 
have the view of a speaking person in video.
We can just define that usage of hlang in video media with non-sign 
language tags, and not relate it to any use of the audio channel 
language. ( as the dropped sentence does.)  So, please reinsert the 
dropped sentence.

  Gunnar
>
> On Tue, Nov 21, 2017 at 10:53 PM, Gunnar Hellström 
>     It was a result of the previous discussion and reasoning, and I
>     think it should be reinserted.
>
>     2. You also changed the title proposal from " 5.4 Media, Language
>     and Modality indications" to "5.4 Usage Notes"
>
>     I think it is better to have a title that tells about the topic of
>     the paragraph. I suggest to use the title I proposed, but I can
>     accept yours if you have a good reason for the change.
>
>     Thanks,
>
>     Gunnar
>
>
>>         I agree.  I made a few minor editorial changes (e.g., moving
>>         some text to a new paragraph):
>>
>>         5.4.  Usage Notes
>>
>>                  Based on the text and comments from Gunnar, brian,
>>                 Paul, and Bernard, here is what I propose to replace
>>                 section 5.4 with:
>>
>>                  5.4. Usage Notes
>>
>>                 This document
>>                 language tags in text
>>              I provide a slightly modified 5.4 proposal, with a bit
>>             more consistent language in the first paragraph, and the
>>             mentioning of further work or application agreement
>>             reinserted. I think that is better than just saying that
>>             it is not defined. I also added the spoken language in
>>             video is a view of a speaker according to recent
>>             discussion in another mail.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Nov 2017 08:20:33 -0800

On Nov 22, 2017, at 8:03 AM, Gunnar Hellström <[email-masked]> wrote:

> What we want is an indication that the user is prepared / desires to have the view of a speaking person in video. 

The problem is that a written/spoken tag in video is ambiguous because it could also represent a desire for captioning. So there is a need to distinguish spoken from written language. We have not had consensus on how to do that, in general.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 22 Nov 2017 08:50:36 -0800

If we need to specify how to request a video stream for a view of the 
speaking person, we could go back to the old text of saying a video 
stream without a language attribute, but I think we don't need to 
specify it in this document.  We've always said that we want to 
produce a simple mechanism that can be more easily deployed, so we 
can gain operational experience to inform an update later.

-------------- Randomly selected tag: ---------------
If God lived on Earth, people would knock out all His windows.
                                             --Yiddish saying

---

From: Keith Drage <[email-masked]>
Date: Wed, 22 Nov 2017 20:39:01 +0000

Why do we keep having to use this construct "non-sign", which in itself 
is entirely meaningless. Surely in this case we are talking about a 
either the absence of a language tag, or the absence of "sgn" within a 
language tag. Why don't we just talk about the absence of "sgn" where 
necessary.

As an aside I note elsewhere in the document we talk about 
"non-emergency calls", which should mean "a call for a non-emergency". 
The correct opposite to emergency call would be "call that is not 
related to an emergency".

There are several other "non-" instances in the document that are 
equally meaningless. I assume "non-realtime xxx" is not intended to mean 
"unrealtime xxx", but rather, "xxx that is not realtime".

Keith

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 22 Nov 2017 22:14:19 +0100

> The problem is that a written/spoken tag in video is ambiguous because it could also represent a desire for captioning. So there is a need to distinguish spoken from written language. We have not h…
Bernard,

We had a reasoning yesterday that it is so unusual to provide text in a 
conversational video call in the video media stream that we could leave 
that usage undefined (it was used as mixed into the video image from the 
sending side in the early 2000s, and it is also possible to send text 
coded text elements in RFC 3640 MPEG4 video coding for presentation in 
the receiving end, but the impression is that these methods are not used 
nowadays in conversational calls) That leaves the only practically used 
case for non-sign language in video media in conversational calls be for 
a view of spoken language.
Randall introduced that view (about captions in video not being used in 
conversational calls) and I agreed. I know that is not total consensus, 
but there were at least not any declared conflicting views.

There are use cases for the use of a view of a speaking person in video.

It would be good if this reasoning makes you change your mind and check 
if we can have consensus for inserting the dropped sentence.

If not, I will stop arguing for that and accept that we need to take the 
effort to define how to indicate this use case at a later stage. The 
rest of section 5.4 is good now and explicitly allows further work and 
application agreements.

Gunnar

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Nov 2017 15:04:54 -0800

On Nov 22, 2017, at 1:14 PM, Gunnar Hellström <[email-masked]> wrote:
>> 
> Randall introduced that view (about captions in video not being used in conversational calls) and I agreed. I know that is not total consensus, but there were at least not any declared conflicting views.

[BA] With speech recognition APIs now approaching realtime performance it is becoming feasible to do captioning in realtime video. There are situations (e.g. recordings of classes posted online) where captioning is required by regulators, and it is more efficient and inclusive to do captioning during the class and record it than to require students to wait for postprocessing to add captions.

> It would be good if this reasoning makes you change your mind and check if we can have consensus for inserting the dropped sentence.
> 
> If not, I will stop arguing for that and accept that we need to take the effort to define how to indicate this use case at a later stage. The rest of section 5.4 is good now and explicitly allows further work and application agreements.
> 
> Gunnar
> 
> --

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 23 Nov 2017 00:47:16 +0100

> [BA] With speech recognition APIs now approaching realtime performance it is becoming feasible to do captioning in realtime video. There are situations (e.g. recordings of classes posted online) wh…
<GH>Yes, I agree completely that speech recognition is a reality for 
real-time captioning today. But do you know implementations that 
transmit it as part of a video media stream? What coding?

---

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

At 10:14 PM +0100 11/22/17, Gunnar Hellström wrote:

>  explicitly allows further work and application agreements

Just as an aside, the text explicitly allowing 
for such is unnecessary; if the draft did not 
prohibit it, it would be permitted.  There's also 
no harm in the text explicitly permitting it.

-------------- Randomly selected tag: ---------------
Dogs believe they are human. Cats believe they are God.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 22 Nov 2017 18:02:09 -0800

On Nov 22, 2017, at 3:47 PM, Gunnar Hellström <[email-masked]> wrote:
>> 
> <GH>Yes, I agree completely that speech recognition is a reality for real-time captioning today. But do you know implementations that transmit it as part of a video media stream? What coding?

Here is an example that used machine learning to provide realtime captions in multiple languages:
https://azure.microsoft.com/en-us/blog/live-real-time-captions-with-azure-media-services-and-player/?cdn=disable

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 23 Nov 2017 12:23:31 +0100

Den 2017-11-23 kl. 03:02, skrev Bernard Aboba:
> On Nov 22, 2017, at 3:47 PM, Gunnar Hellström 

<GH>Yes, a nice example.  Even if it is not from our application area - 
conversational calls, and not initiated by SDP, and not using a video 
media stream, but a multiplexed RTMP TCP based message stream with 
interleaved video chunks and text chunks, it is an example that reminds 
us that something similar could be set up in a conversational call with 
SDP and using video media with MPEG4 according to RFC 3640, 4337 or 6381.

That indicates to us that we have cases that are even less supported by 
our current draft. The video/mp4 media can contain video and audio and 
text. If that is used for a conversational call, we would need to 
collect 'hlang' attributes for all three modalities in the video media 
description, and possibly get them all agreed, and that is against one 
of our basic statements in section 3:

    (Negotiating multiple simultaneous languages within a media stream is
    out of scope of this document.)

So, ok, let us for now assume that we limit the application to 
traditional conversational calls with one media and language per stream 
and no multiplexing.

Gunnar