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

[Bernard Aboba <[e-mail]>]

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
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. "

[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 <
[e-mail]> 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
>
> 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.
>
> 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 [e-mail]://www.ietf.org/mailman/listinfo/slim
>
>
> --
> -----------------------------------------
> Gunnar Hellström
> [e-mail]
> [phone]
>
>