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

[Randall Gellens <[e-mail]>]

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:

>  Den 2017-11-21 kl. 16:59, skrev Bernard Aboba:
>
>>  [BA] LGTM.  Do you recall what the objection 
>> was to the term "spoken/written language"?
>>
>  <GH> It was in this mail in the archive:
> 
> <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:
>
>   >>>  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. 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:
>
>  "   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>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
>
>>
>>  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 
>> <<mailto:[e-mail]>[e-mail]> 
>> wrote:
>>
>>  Den 2017-11-20 kl. 23:16, skrev Bernard Aboba:
>>
>>>  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."
>>
>>  <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 
>> <<mailto:[e-mail]>[e-mail]> 
>> wrote:
>>
>>  A new proposal for new text taking in latest 
>> discussion of Bernard, Paul and Brian:
>>
>>  -----Old text----
>>
>>  5.4 Undefined Combinations
>>
>>
>>
>>     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------------
>>  5.4 Media, Language and Modality indications
>>
>>  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.
>>
>>  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, 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:
>>
>>>  Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:
>>>
>>>>  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?
>>>
>>  <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 
>> 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".
>>
>>  Yes, right, that is better wording.
>>
>>  Gunnar
>>
>>>
>>>
>>>
>>
>>
>>  On Mon, Nov 20, 2017 at 9:25 AM, Gunnar 
>> Hellström 
>> <<mailto:[e-mail]>[e-mail]> 
>> 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----
>>
>>  5.4 Undefined Combinations
>>
>>
>>
>>     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------------
>>  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:
>>
>>>  At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>>>
>>>>   "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.
>>>>
>>
>>  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:[e-mail]><mailto:[e-mail]><mailto:[e-mail]>[e-mail]> 
>>> 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.
>>>
>>>   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.
>>>
>>>      The problem of knowing which language tags are signed and which are
>>>      not is out of scope of 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.
>>>
>>
>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  <mailto:[e-mail]>[e-mail]
>>  [phone]
>>
>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  <mailto:[e-mail]>[e-mail]
>>  [phone]
>>
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  <mailto:[e-mail]>[e-mail]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  <mailto:[e-mail]>[e-mail]
>>  [phone]
>>
>>
>>
>>  --
>>  -----------------------------------------
>>  Gunnar Hellström
>>  Omnitor
>>  <mailto:[e-mail]>[e-mail]
>>  [phone]
>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellström
>  Omnitor
>  <mailto:[e-mail]>[e-mail]
>  [phone]
>
>  _______________________________________________
>  SLIM mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/slim


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Premature optimization is the root of all evil
                              --C. A. R. Hoare