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

[Randy Presuhn <[e-mail]>]

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