Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-languag

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.