I have some allergy to the SHALL language: there is no way to automatically
determine conformance. Many language tags represent nonsensical values, due to
the nature of language tag composition. Content providers need to use care in
selecting the tags that they use and this section is merely pointing out good
guidance for tag selection, albeit in a heavy-handed way. BCP47 RFC 5646
Section 4.1 [1] already provides most of this guidance and a reference to that
source might be useful here, if only because that document requires it:
<quote>
Standards, protocols, and applications that reference this document
normatively but apply different rules to the ones given in this
section MUST specify how language tag selection varies from the
guidelines given here.
</quote>
I would suggest reducing the SHALL items to SHOULD.
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.
Regards,
Addison
Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)
Internationalization is not a feature.
It is an architecture.
[1] https://tools.ietf.org/html/bcp47#section-4.1
-----Original Message-----
From: SLIM [mailto:slim-bounces(_at_)ietf(_dot_)org] On Behalf Of Gunnar
Hellström
Sent: Tuesday, February 14, 2017 11:59 AM
To: Randy Presuhn <randy_presuhn(_at_)alumni(_dot_)stanford(_dot_)edu>;
ietf(_at_)ietf(_dot_)org; slim(_at_)ietf(_dot_)org
Subject: Re: [Slim] IETF last call for
draft-ietf-slim-negotiating-human-language (Section 5.4)
Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:
Hi -
On 2/14/2017 9:40 AM, Randall Gellens wrote:
At 11:01 AM +0100 2/14/17, Gunnar Hellström wrote:
My proposal for a reworded section 5.4 is:
5.4. Unusual language indications
It is possible to specify an unusual indication where the language
specified may look unexpected for the media type.
For such cases the following guidance SHALL be applied for the
humintlang attributes used in these situations.
1. A view of a speaking person in the video stream SHALL, when it
has relevance for speech perception, be indicated by a Language-Tag
for spoken/written language with the "Zxxx" script subtag to
indicate that the contents is not written.
2. Text captions included in the video stream SHALL be indicated
by a Language-Tag for spoken/written language.
3. Any approximate representation of sign language or
fingerspelling in the text media stream SHALL be indicated by a
Language-Tag for a sign language in text media.
4. When sign language related audio from a person using sign
language is of importance for language communication, this SHALL be
indicated by a Language-Tag for a sign language in audio media.
[RG] As I said, I think we should avoid specifying this until we have
deployment experience.
...
From a process perspective, it's far easier to remove constraints as a
specification advances than it is to add them.
I agree. It is often better to specify normatively as far as you can imagine,
so that interoperability and good functionality is achieved.
Stopping halfway and have MAY in the specifications creates uncertainty and
less useful specifications.
Furthermore, in this case we succeeded to discuss and sort out the
interpretation of the unusual combinations.
I am very glad that we sorted out the difference between 1 and 2, and they are
both real-life cases.
3 is not at all common, but I have seen products claiming to work for real-time
communication with sign representation in text. So it is good to have it
settled.
4. Is a bit more far fetched and may cause some questioning if there are real
cases, and where the line should be drawn between indicating a spoken languge
in the audio stream and indicating a sign language in the audio stream.
As I wiew it now, this combination will be very rare, but it is anyway good to
be specific and normative about its coding.
Gunnar
Randy
--
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar(_dot_)hellstrom(_at_)omnitor(_dot_)se
+46 708 204 288
_______________________________________________
SLIM mailing list
SLIM(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/slim