Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language

Randall Gellens <rg+ietf@randy.pensive.org> Sun, 19 November 2017 23:52 UTC

Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C021201FA for <slim@ietfa.amsl.com>; Sun, 19 Nov 2017 15:52:59 -0800 (PST)
X-Quarantine-ID: <lIDAtKN-Iuo8>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIDAtKN-Iuo8 for <slim@ietfa.amsl.com>; Sun, 19 Nov 2017 15:52:50 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B9FEC124BE8 for <slim@ietf.org>; Sun, 19 Nov 2017 15:52:50 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 19 Nov 2017 15:52:55 -0800
Mime-Version: 1.0
Message-Id: <p06240600d637c6f98ecc@[99.111.97.136]>
In-Reply-To: <CAOW+2dsZtuciPiKMfif=ZmUqBcUd9TyYtL5gPYDp7ZfLOHHDBA@mail.gmail.com>
References: <CAOW+2dsZtuciPiKMfif=ZmUqBcUd9TyYtL5gPYDp7ZfLOHHDBA@mail.gmail.com>
X-Mailer: Eudora for Mac OS X
Date: Sun, 19 Nov 2017 15:52:47 -0800
To: Bernard Aboba <bernard.aboba@gmail.com>, slim@ietf.org
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/dg9WyX1FBIXh3ZskUDYKnenOgzs>
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Nov 2017 23:53:00 -0000

My view of issue #43 remains that we do not need to specify a 
mechanism for determining which tags are signed.  In the email 
discussion of the past month or so, I fear we are drifting into 
adding complexity rather than removing it.  I think the way forward 
is to keep this document as simple as possible.  As Bernard notes in 
his email of 10/23, there is no benefit in this case of explicitly 
saying that certain things are not defined.  Since the document does 
not define them, they are undefined in the document.

At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>  In other words,it is not clear to me how Section 5.4's discussion 
> of scope improves or clarifies the situation in any way - and there 
> is some possibility that it could cause problems.


I believe comment #43 should be closed as no longer applicable, since 
the text against which it was generated has been deleted.  (I've said 
this before, and I believe it remains the case.)

The comment from which #43 derives was made against a version of the 
document that had text explicitly discussing signed versus unsigned 
tags.  That text was subsequently deleted.

Here is the comment from which #43 derived:

>     5.2.  New 'humintlang-send' and 'humintlang-recv' attributes
>
>     Note that while signed language tags are used with a video stream
>  to
>     indicate sign language, a spoken language tag for a video stream
>  in
>     parallel with an audio stream with the same spoken language tag
>     indicates a request for a supplemental video stream to see the
>     speaker.
>
>  And there's a similar paragraph in 5.4:
>
>>     A spoken language tag for a video stream in conjunction with an
>  audio
>>     stream with the same language might indicate a request for
>>     supplemental video to see the speaker.
>
>  I think this mechanism needs to be described more exactly, and in
>  particular, it should not depend on the UA understanding which
>  language tags are spoken language tags.  It seems to me that a
>  workable rule is that there is an audio stream and a video stream and
>  they specify exactly the same language tag in their respective
>  humintlang attributes.  In that case, it is a request for a spoken
>  language with simultaneous video of the speaker, and those requests
>  should be considered satisfied only if both streams can be
>  established.

The offending text that was in 5.2 and 5.4 was deleted.

The only remaining text that even mentions the issue is Section 5.4:

    The behavior when specifying a non-signed language tag for a video
    media stream, or a signed language tag for an audio or text media
    stream, is not defined in this document.

    The problem of knowing which language tags are signed and which are
    not is out of scope of this document.

So, let's delete Section 5.4 and be done with it.  Neither of the 
statements is necessary.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Make it right before you make it faster.