Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
Randall Gellens <rg+ietf@randy.pensive.org> Wed, 15 February 2017 23:01 UTC
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273541293DA; Wed, 15 Feb 2017 15:01:10 -0800 (PST)
X-Quarantine-ID: <7Lf0T39jQkal>
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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 7Lf0T39jQkal; Wed, 15 Feb 2017 15:01:08 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFA0129721; Wed, 15 Feb 2017 15:01:08 -0800 (PST)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 15 Feb 2017 14:52:59 -0800
Mime-Version: 1.0
Message-Id: <p06240606d4ca8c757453@[99.111.97.136]>
In-Reply-To: <e1ce6bbaaf624c1e88d31c72440093ba@EX13D08UWB002.ant.amazon.com>
References: <20170213161000.665a7a7059d7ee80bb4d670165c8327d.917539e857.wbe@email0 3.godaddy.com> <ddc5af1d-f084-f57e-d6c9-5963e4fe98d3@omnitor.se> <4c4ef65a-a907-cf5e-4b2c-835fb55d0146@omnitor.se> <p06240603d4c8f105055e@[99.111.97.136]> <434a4f06-f034-46ca-9df7-f59059e67e41@alumni.stanford.edu> <843f0cc1-2686-162d-25dc-0075847579bc@omnitor.se> <44474907d69a42a0adb66cdc4933603a@EX13D08UWB002.ant.amazon.com> <ba7f397b-59ae-c549-cd1a-e22e1b73b3c1@omnitor.se> <e1ce6bbaaf624c1e88d31c72440093ba@EX13D08UWB002.ant.amazon.com>
X-Mailer: Eudora for Mac OS X
Date: Wed, 15 Feb 2017 15:01:05 -0800
To: "Phillips, Addison" <addison@lab126.com>, Gunnar Hellström <gunnar.hellstrom@omnitor.se>, Randy Presuhn <randy_presuhn@alumni.stanford.edu>, "ietf@ietf.org" <ietf@ietf.org>, "slim@ietf.org" <slim@ietf.org>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/cD7c3zeBzvU8JYKHlP0q14yC0GI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 23:01:10 -0000
Hi Addison, Please see in-line. At 5:12 PM +0000 2/15/17, Addison Phillips wrote: > Gunnar replied: >> >> Den 2017-02-14 kl. 21:39, skrev Phillips, Addison: >> > I have some allergy to the SHALL language: there is no way to >> automatically >> determine conformance. Many language tags represent nonsensical values, due >> to the nature of language tag composition. Content providers need >> to use care >> in selecting the tags that they use and this section is merely >> pointing out good >> guidance for tag selection, albeit in a heavy-handed way. BCP47 RFC 5646 >> Section 4.1 [1] already provides most of this guidance and a >> reference to that >> source might be useful here, if only because that document requires it: >> > >> > <quote> >> > Standards, protocols, and applications that reference this document >> > normatively but apply different rules to the ones given in this >> > section MUST specify how language tag selection varies from the >> > guidelines given here. >> > </quote> >> > >> > I would suggest reducing the SHALL items to SHOULD. >> Accepted. >> That also opens up for another use we have discussed before but been advised >> to not use. That is to indicate use of written language by >> attaching a script >> subtag even if the script subtag we use is suppressed by BCP 47. >> We can dro that >> need however, with the use of the Zxxx script subtag for >> non-written, and clearly >> include that usage in our specification as required from BCP 47. > > I don't necessarily think that mandating a script subtag as a > signal of written content (vs. spoken content) is that useful. In > most protocols, the written nature of the content is indicated by > the presence of text. Trying to coerce the language modality via > language tags seems complicated, especially since most language > tags are harvested from the original source. Introducing processes > to evaluate and insert or remove script subtags seems unnecessary > to me. That said, I have no objection to content using script > subtags if they are useful. > >> > >> > I'm not sure what #2 really means. Shouldn't text captions be >> indicated by the >> written language rather than the spoken language? And I'm not sure what >> "spoken/written language" means. >> #2 was: " >> >> 2. Text captions included in the video stream SHALL be indicated >> by a Language-Tag for spoken/written language." >> >> Yes, the intention is to use written language in the video stream. There are >> technologies for that. > > I'm aware of that. My concern is that in this case "spoken/written" > is applied to "text captions", which are not spoken be definition? > This section is talking about the differences between identifying > spoken and written language. The text captions fall into the > written side of the equation, no? Keep in mind that the focus of the draft is enabling language negotiation along with media negotiation for interactive communications. In this context, as I noted in previous replies, real-time text captions for sign language in video is a service. A mechanism for requesting services needs to be carefully thought out in the WG and not added to the current draft at the last minute. > > I'd probably prefer to see something like "2. Text captions > included in the video stream SHOULD include a Language-Tag to > identify the language." > >> Since the language subtags in the IANA registry are combined for spoken >> languages and written languages, I call them Language-Tags for >> spoken/written >> language. > > The language subtags are for languages--all modalities. My comment > here is that "spoken/written" adds no information. > >> It would be misleading to say that we use a Language-Tag for a written >> language, because the same tag could in another context mean a spoken > > language. > > One uses a Language-Tag for indicating the language. When the text > is written, sometimes the user will pick a different language tag > (zh-Hant-HK) than they might choose for spoken text (yue-HK, > zh-cmn-HK, etc.). Sometimes (actually, nearly all the time except > for special cases) the language tag for the spoken and written > language is the same tag (en-US, de-CH, ja-JP, etc.). Again, the > modality of the language is a separate consideration from the > language. Nearly always, it is better to use the same tag for both > spoken and written content rather than trying to use the tag to > distinguish between them: different Content-Types require different > decoders anyway, but it is really useful to say "give me all of the > 'en-US' content you have" or "do you have content for a user who > speaks 'es'" Requesting all content available in a specific language is outside the scope of the draft, which is enabling language negotiation along with media negotiation for interactive communications. One key example is a user placing an emergency call. The call setup can negotiate both language and media for interactive communication between the emergency services answering point and the user. > >> Since we have the script subtag Zxxx for non-written, we do not need to >> construct an explicit tag for the written language tag, it should >> be sufficient with >> our specification of the use in our case. > > In case it isn't clear aboe, I oppose introducing the 'Zxxx' subtag > save for cases where the non-written nature of the content is > super-important to the identification of the language. >> >> In my latest recent proposal, I still have a very similar wording. >> Since you had >> problems understanding it, there might still be a need to tune it. Can you >> propose wording? >> This is the current proposal: >> >> " 2. Text captions included in the video stream SHOULD be indicated >> by a humintlang attribute with Language-Tag for spoken/written language. >> " > > I did that above. I think it is useful not to over-think it. When I > see "Content-Type: video/mpeg; Content-Language: en-GB", I rather > expect audio content in English and not written content (although > the video stream might also includes pictures of English text such > as the titles in a movie). When, as in this case, setting up a > negotiated language experience, interoperability is most aided by > matching the customer's language preferences to available > resources. This is easiest when customers do not get carried away > with complex language tags (ranges in BCP 47 parlance, e.g. > tlh-Cyrl-AQ-fonupa) and systems do not have to introspect the > language tags, inserting and removing script subtags to match the > various language modes. > > Addison > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The First Amendment is often inconvenient. But that is besides the point. Inconvenience does not absolve the government of its obligation to tolerate speech. --Justice Anthony Kennedy, in 91-155
- Re: IETF last call for draft-ietf-slim-negotiatin… Bernard Aboba
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Bernard Aboba
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- RE: [Slim] IETF last call for draft-ietf-slim-neg… Doug Ewell
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randy Presuhn
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- RE: [Slim] IETF last call for draft-ietf-slim-neg… Phillips, Addison
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randy Presuhn
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- RE: [Slim] IETF last call for draft-ietf-slim-neg… Phillips, Addison
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Bernard Aboba
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Gunnar Hellström
- Re: [Slim] IETF last call for draft-ietf-slim-neg… Randall Gellens