ietf
[Top] [All Lists]

Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)

2017-02-14 18:21:50
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.

Randy

<Prev in Thread] Current Thread [Next in Thread>