At 4:21 PM -0800 2/14/17, Randy Presuhn wrote:
Hi -
On 2/14/2017 2:43 PM, Randall Gellens wrote:
At 8:59 PM +0100 2/14/17, Gunnar Hellström wrote:
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.
My reading of what Randy says is the opposite of Gunnar's. In my
reading, Randy points out that is it easier to remove the SHOULD NOT in
the future then it is to change the meaning of the combinations or
switch to a different mechanism.
In my experience, it's better to specify only what we know we need and
what we know we understand. Speculative specifications "as far as you
can imagine" more often lead to interoperability problems, unnecessary
complexity, limitations on what's needed in the future, and divergent
implementations.
I think the difference in your positions comes down to
(1) your respective notions of "what we know we need and what we
know we understand";
(2) whether you believe that the interoperability and conformance
consequences of removing a "SHOULD NOT" could be the same
as those merely retaining a "MUST" or "SHALL" - this determines
whether Randy G.'s proposal provides a path for some future
revision to mandate (if deployment experience substantiates the
need/understanding) the behavior proposed by Gunnar. That path
is not at all obvious to me.
The purpose of the draft is to enable the two
endpoints of a real-time communication session to
agree which languages and media to use for
interactive communication. We have a mechanism
of adding language tags to media stream
negotiations. In most cases, the language and
media modality are an obvious fit. There are
combinations of media and language where the
meaning is not so obvious, specifically, signed
language tags with a audio or text, and
non-signed language tags with video. My proposal
is that we say offerer SHOULD NOT send such
combinations and answerer MAY ignore language.
This allows future specifications for the
underlying uses Gunnar wants (such as real-time
subtitles in video and signed equivalents in
text). Such future specifications could define a
use for the language and media combinations and
remove the SHOULD NOT send and MAY ignore, or
could define a new mechanism. I don't think we
know enough now to dictate what the solution
should be.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly selected tag: ---------------
Dogs have owners. Cats have staff.