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

Bernard Aboba <bernard.aboba@gmail.com> Mon, 20 November 2017 03:47 UTC

Return-Path: <bernard.aboba@gmail.com>
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 B6001126D45 for <slim@ietfa.amsl.com>; Sun, 19 Nov 2017 19:47:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1FLETZTR5jGG for <slim@ietfa.amsl.com>; Sun, 19 Nov 2017 19:47:47 -0800 (PST)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A894124E15 for <slim@ietf.org>; Sun, 19 Nov 2017 19:47:47 -0800 (PST)
Received: by mail-vk0-x22e.google.com with SMTP id o70so4782270vkc.9 for <slim@ietf.org>; Sun, 19 Nov 2017 19:47:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ApS77iY+ZTe4IOVv3bGo6eibWExU1rveH1sWxdbTEFI=; b=uS//r296+uBXI2vMjFsCZ7zD1pTUIx9BS+GfF6LamuybBxZUTX263bOmu2Ju1a2l7l Kej1+RioLSo625+wQ26dlQEBD/hCHpah0irUvpCMInIYyRJLijkLQtiy4vj0ffJkPBjM N6sE38gZvsCNtU6tPi07z2XXTGWI8kEQI3tm6Jr69MNla+DW0gBf94kkNsmLuNGk+SAz gqo9YrI0b25rmw3HP77QXZmBEsK6676t40vRgPsG3V3vm2v7rQmGRmW5TbDNzdiBZVEw 9YTjlYySLlXSAF/NKCHWCI4/bxB8uwkwdIvTtriY7EsXAB7Hf8HeW6ZQViHq26jUwqNm I/SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ApS77iY+ZTe4IOVv3bGo6eibWExU1rveH1sWxdbTEFI=; b=bbwLOu7p6bFjWpFBmdLxtVGKGoaSIn+X9Wotjty7cmEJ6ghtrm5I6wcKvfk9un+YYZ fG6syVYKRxPVJ4PrB4SHBOcl9rX7/MnmUelSkCaUCk55Fr6ir3O9n7CcZT0cgb5Dph5V SMfCqAfx5fVi1Te2VZgVBLpw/3nE8477mAb30uFCItzCE42bZXm5h4FPIEiVHvL366Cx NNoSy9euls5TRDtk3nVNDUGx3yZiSWTbCe/J33MtYKujhSEYP+mcRklrwgacWPYtw8CD 2BT4r5MXTY/D4DEGUNa/Wl1Aawt/5qufEG70muX3THvChVxwoouVvrJJNmvAzW9o+zrq WMRw==
X-Gm-Message-State: AJaThX5unbvQnNtS+7kGui5tjSAMxymUZWiYcUbQtuJkdesy8zW2RtBR TBsRtFXB7Ao5DyXGbX2iXpnDfVcJ300pGcmHGRcBq22E
X-Google-Smtp-Source: AGs4zMaxBRf+t7S6b9s3o6uZ9wb0fcwSnQkaOeCe8keeVQU5PrJCpJIRsWN/85qW4PfAuSxITYlLxZDmGfnC4GG3ayQ=
X-Received: by 10.31.5.66 with SMTP id 63mr9586637vkf.15.1511149666314; Sun, 19 Nov 2017 19:47:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Sun, 19 Nov 2017 19:47:25 -0800 (PST)
In-Reply-To: <p06240600d637c6f98ecc@99.111.97.136>
References: <CAOW+2dsZtuciPiKMfif=ZmUqBcUd9TyYtL5gPYDp7ZfLOHHDBA@mail.gmail.com> <p06240600d637c6f98ecc@99.111.97.136>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Sun, 19 Nov 2017 19:47:25 -0800
Message-ID: <CAOW+2dv5NSiCbW=p1exvPV=PF8YCVdiz2gi-OCxmaUB-jGe22w@mail.gmail.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: slim@ietf.org
Content-Type: multipart/alternative; boundary="001a1143dd5a102e6d055e61f35d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/52HIq6TRHa5GJuNR0NtrC0D_-6U>
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: Mon, 20 Nov 2017 03:47:50 -0000

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

[BA]  I agree that Section 5.4 does not add much value as it stands.

"Non-signed" is not used outside of Section 5.4, so there would not appear
to be a need to define it if Section 5.4 were to be deleted.

However, the term "signed" is used in 7 other places in the document other
than in Section 5.4.

So we may need to find a reference to define that term.

If Gunnar's suggested definition can be confirmed,  this might be as simple
as adding a reference to the IANA language tag repository.

On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens <rg+ietf@randy.pensive.org>
wrote:

> 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.
>