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

Bernard Aboba <bernard.aboba@gmail.com> Mon, 20 November 2017 18:41 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 AFBF912704B for <slim@ietfa.amsl.com>; Mon, 20 Nov 2017 10:41:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 GhPuhFA6XtCw for <slim@ietfa.amsl.com>; Mon, 20 Nov 2017 10:41:31 -0800 (PST)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 048BB12706D for <slim@ietf.org>; Mon, 20 Nov 2017 10:41:27 -0800 (PST)
Received: by mail-ua0-x22b.google.com with SMTP id 108so6573793uaf.2 for <slim@ietf.org>; Mon, 20 Nov 2017 10:41:27 -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=IXASU4FwabK9yr+sr5imaO6sUM4cKh+kFwFrhRWS4ac=; b=s1205gNV/ZivKGem7rq2AHCWlOrHAR8tZR07AvzdFGeH7+WWPiPsYZi5dlvrtalSro sEFVTKbN3ralD0RynX1e5f0zKx1ahsY6E5IjWSxfuYsMhaaRW2r2+j53g41gXtCQU4C2 N3pyE07CeT8vdgbPsWt16h4Ntt1HJSP4HSo73KB63AGMc7NIMsSS5eLr6W81dpe+yb/e G9/7Rolzda7CbYWdsZRJq9TSBwZzHg2Sr5keBxcGurznnNcnwvZEhRJWeLewEFcjA5U7 o6NriiFtJgTFZpTsUTEf5YGWHcp4eGD3WV6Cb8zYjnD6KaDmVv8Ijs84tDDLpVQT3D1I Fhqg==
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=IXASU4FwabK9yr+sr5imaO6sUM4cKh+kFwFrhRWS4ac=; b=afyn7YL504beC3rsasb6w9/P6YXkwXCFsVS+x6Rd9zEXETszGrahGnkPf+NiST8lGu SFg2OclKaZE7AkkQP/PRD6//d/1JkhY7MREewzlmaMpYyK+H9+W6ael47EsrI+LLjoMi 5xBnI2cNlvBXBUnu9lxfviCaBuqeyDWU49eLAMFg0lv54AiFVp81WYmxOFJfTseJ3hZK 7bSejKEJAVISrn92uafGqcBBOoAqPlu5+uuGk3XyWP4j0RAkI8PbO4C6tA2HhCgSry4M jyBoS/Tfy1DleIzBWf3s+9ImlpPi4dedTgXPxRHHVzzml9Qdv5y5grOEk1aGDQA0Jm9D RiHQ==
X-Gm-Message-State: AJaThX51MovnO6rZs+riEZtSGNhM2wT/nRaI54c4x15q0E0kFMfL4YJ2 Ao23s4zDjcEJPdzoHhhlEFHrUHJaOM0n8NOnNSsy2EGY
X-Google-Smtp-Source: AGs4zMafDZlxTQNXr6Oaor9hbUTlOas41j0m5NpD/Y6vQQ7w5e+cuQ9YyvTYhZuChbOc5ysE4slhVAuu3MAWYe6uDSw=
X-Received: by 10.159.44.130 with SMTP id w2mr6992938uaj.202.1511203286716; Mon, 20 Nov 2017 10:41:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.54.230 with HTTP; Mon, 20 Nov 2017 10:41:06 -0800 (PST)
In-Reply-To: <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>
References: <CAOW+2dsZtuciPiKMfif=ZmUqBcUd9TyYtL5gPYDp7ZfLOHHDBA@mail.gmail.com> <p06240600d637c6f98ecc@99.111.97.136> <CAOW+2dv5NSiCbW=p1exvPV=PF8YCVdiz2gi-OCxmaUB-jGe22w@mail.gmail.com> <p06240600d6389cd2043f@99.111.97.136> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 20 Nov 2017 10:41:06 -0800
Message-ID: <CAOW+2dtpRoeYkMJzX9vyNUojJDax4DQUU2F4PauBwt1sm-83Hg@mail.gmail.com>
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@omnitor.se>
Cc: Randall Gellens <rg+ietf@randy.pensive.org>, slim@ietf.org
Content-Type: multipart/alternative; boundary="089e082558b8169d7a055e6e6fc0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/-XTt-IYn5G5Jr7m7aR5sFpOSxE8>
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 18:41:35 -0000

Gunnar said:

"5.4 Media, Language and Modality indications

The combination of Language tags and other information in the media
descriptions should be composed so that the intended modality can be
concluded by the negotiating parties. "

[BA] Is the "should" intended to be normative?

The following combinations of language tags and media provide obvious
information about the modality: sign language tags in video media indicate
signed modality... A sign language can be identified by the existence in
the IANA registry of language subtags according to BCP 47 [RFC5646] of the
language subtag with the Type field "extlang" combined with the Prefix
field value "sgn".  A specific spoken or written language can be identified
by not having any such "sgn" Prefix.

Use of language may appear in other media, such as "message" and
"application". Video media may be used for other modalities than signed.
Such use may be supported by further work or application specific
agreements or indications for evaluation of the intended modality. "

[BA] Assume we can confirm the mechanism for distinguishing
signed/non-signed languages, this part seems relatively solid.

spoken language tags for audio media indicate spoken modality and written
language tags for text media indicate written modality. The examples in
this specification are all from this set of three obvious
language/media/modality combinations.

[BA]  This is where the ground gets less solid - we don't really have a
general mechanism for distinguishing spoken and written modality among
non-signed languages. Perhaps we should just say "language tags in audio
media indicate spoken modality and language tags in text media indicate
written modality".





On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellström <
gunnar.hellstrom@omnitor.se> wrote:

> It is not the signed languages that are causing the problem. It is the
> spoken and written, when used in other media than the obvious audio and
> text media.
>
> And we should specify what is obvious and well defined and not, so here is
> a new shorter proposal for section 5.4.
>
> -----Old text----
>
> 5.4 Undefined Combinations
>
>    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.
>
> -----New text------------
> 5.4 Media, Language and Modality indications
>
> The combination of Language tags and other information in the media
> descriptions should be composed so that the intended modality can be
> concluded by the negotiating parties. The following combinations of
> language tags and media provide obvious information about the modality:
> sign language tags in video media indicate signed modality, spoken language
> tags for audio media indicate spoken modality and written language tags for
> text media indicate written modality. The examples in this specification
> are all from this set of three obvious language/media/modality combinations.
>
> A sign language can be identified by the existence in the IANA registry of
> language subtags according to BCP 47 [RFC5646] of the language subtag with
> the Type field "extlang" combined with the Prefix field value "sgn".
> A specific spoken or written language can be identified by not having any
> such "sgn" Prefix.
>
> Use of language may appear in other media, such as "message" and
> "application". Video media may be used for other modalities than signed.
> Such use may be supported by further work or application specific
> agreements or indications for evaluation of the intended modality.
>
> -------------------------------------------------------------------End of
> new text---------------------------------------
>
> Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>
> At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>
>  "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.
>
>
> But none of those instances are normative.
>
>  So we may need to find a reference to define that term.
>
>
> Because the uses of the term are descriptive and mostly background, I do
> not think we need to add a definition or even a reference to a definition
> of the term.
>
> --Randall
>
>
>  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 <<mailto:rg+ietf@randy.
> pensive.org> <rg+ietf@randy.pensive.org>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.
>
>
>
>
> --
> -----------------------------------------
> Gunnar Hellström
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>