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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]