From nobody Fri Dec 1 09:23:44 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA84D1275C5; Fri, 1 Dec 2017 09:23:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: slim@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151214901766.18140.10271542818842557709@ietfa.amsl.com> Date: Fri, 01 Dec 2017 09:23:37 -0800 Archived-At: Subject: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-19.txt X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 17:23:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Selection of Language for Internet Media WG of the IETF. Title : Negotiating Human Language in Real-Time Communications Author : Randall Gellens Filename : draft-ietf-slim-negotiating-human-language-19.txt Pages : 16 Date : 2017-12-01 Abstract: Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. This document adds new SDP media-level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important with emergency calls, where a call can be handled by a call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non-emergency calls as well (as an example, when calling a company call center). This document describes the need and a solution using new SDP media attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-19 https://datatracker.ietf.org/doc/html/draft-ietf-slim-negotiating-human-language-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-slim-negotiating-human-language-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 1 15:17:36 2017 Return-Path: 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 5B270124234 for ; Fri, 1 Dec 2017 15:17:35 -0800 (PST) X-Quarantine-ID: 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 jJ-JLswqYEkV for ; Fri, 1 Dec 2017 15:17:33 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 634891200CF for ; Fri, 1 Dec 2017 15:17:33 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 1 Dec 2017 15:17:45 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> X-Mailer: Eudora for Mac OS X Date: Fri, 1 Dec 2017 15:17:29 -0800 To: Keith Drage , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Proposed 5.4 text X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 23:17:35 -0000 Hi Keith, The document uses the terms "sign language tag"=20 and "non-sign language tag", both terms applying=20 to language tags. Neither term is used in the=20 absence of a tag. The two terms are defined in=20 Section 5.4. I do not see why use of the terms=20 is unclear or harmful, much less "entirely=20 meaningless." Along these lines, I don't see how=20 the use of the "non-" prefix elsewhere is=20 confusing or unclear; this is a very common=20 prefix to use in Internet Drafts and RFCs. --Randall At 8:39 PM +0000 11/22/17, Keith Drage wrote: > Why do we keep having to use this construct=20 > "non-sign", which in itself is entirely=20 > meaningless. Surely in this case we are talking=20 > about a either the absence of a language tag,=20 > or the absence of "sgn" within a language tag.=20 > Why don't we just talk about the absence of=20 > "sgn" where necessary. > > As an aside I note elsewhere in the document we=20 > talk about "non-emergency calls", which should=20 > mean "a call for a non-emergency". The correct=20 > opposite to emergency call would be "call that=20 > is not related to an emergency". > > There are several other "non-" instances in the=20 > document that are equally meaningless. I assume=20 > "non-realtime xxx" is not intended to mean=20 > "unrealtime xxx", but rather, "xxx that is not=20 > realtime". > > Keith > > On 22-Nov-17 2:17 AM, Bernard Aboba wrote: > >> Looks good to me. >> >> On Tue, Nov 21, 2017 at 3:17 PM, Randall=20 >> Gellens=20 >> <rg+ietf@randy.pensive.org>=20 >> wrote: >> >> I agree. I made a few minor editorial changes=20 >> (e.g., moving some text to a new paragraph): >> >> 5.4. Usage Notes >> >> A sign language tag with a video media stream is interpreted as an >> indication for sign language in the video stream. A non-sign >> language tag with a text media stream is interpreted as an >> indication for written language in the text stream. A non-sign >> language tag with an audio media stream is interpreted as an >> indication for spoken language in the audio stream. >> >> This document does not define any other use for language tags in >> video media (such as how to indicate visible captions in the video >> stream). >> >> In the IANA registry of language subtags per BCP 47 [RFC5646], a >> language subtag with a Type field "extlang" combined with a Prefix >> field value "sgn" indicates a sign language tag. The absense of >> such "sgn" prefix indicates a non-sign language tag. >> >> This document does not define the use of sign language tags in text >> or audio media. >> >> This document does not define the use of language tags in media >> other than interactive streams of audio, video, and text (such as >> "message" or "application"). Such use could be supported by future >> work or by application agreement. >> >> >> At 11:50 PM +0100 11/21/17, Gunnar Hellstr=F6m wrote: >> >> Den 2017-11-21 kl. 23:08, skrev Randall Gellens: >> >> Based on the text and comments from Gunnar,=20 >> brian, Paul, and Bernard, here is what I=20 >> propose to replace section 5.4 with: >> >> 5.4. Usage Notes >> >> A sign language tag with a video stream is interpreted as an >> indication for sign language in the video stream. A non-sign >> language tag with text media is interpreted as an indication for >> written language. A non-sign language tag with audio media is >> interpreted as an indication for spoken language. >> >> In the IANA registry of language subtags per BCP 47 [RFC5646], a >> language subtag with a Type field "extlang" combined with a Prefix >> field value "sgn" indicates a sign language tag. The absense of >> such "sgn" prefix indicates a non-sign language tag. This document >> does not define any other use for language tags in video media >> (such as how to indicate visible captions). >> >> This document does not define the use of sign language tags in text >> or audio media. >> >> This document does not define the use of language tags in media >> other than interactive streams of audio, video, and text (such as >> "message" or "application"). >> >> Good, I hope that "non-sign language" can be an accepted term. >> I provide a slightly modified 5.4 proposal,=20 >> with a bit more consistent language in the=20 >> first paragraph, and the mentioning of further=20 >> work or application agreement reinserted. I=20 >> think that is better than just saying that it=20 >> is not defined. I also added the spoken=20 >> language in video is a view of a speaker=20 >> according to recent discussion in another mail. >> I really hope to find that we are converging now. >> >> ------------------------------new text=20 >> ------------------------------------------- >> 5.4 Media, Language and Modality indications >> >> A sign language tag with video media is interpreted as an >> indication for sign language in the video stream. A non-sign >> language tag with text media is interpreted as an indication for >> written language. A non-sign language tag with audio media is >> interpreted as an indication for spoken language. A non-sign >> language tag with video media is interpreted as a view of a >> speaking person. This document does not define any other >> use for language tags in video media (such as how to indicate >> visible captions in the video stream). >> >> In the IANA registry of language subtags per BCP 47 [RFC5646], a >> language subtag with a Type field "extlang" combined with a Prefix >> field value "sgn" indicates a sign language tag. The absense of >> such "sgn" prefix indicates a non-sign language tag. >> >> This document does not define the use of sign language tags in text >> or audio media. This document does not define=20 >> the use of language tags in media >> other than interactive streams of audio, video, and text (such as >> "message" or "application"). Such use may be supported by further work >> or application specific agreements. >> >> >>=20 >> -------------------------------------------------------------------------= -------------------- >> Gunnar >> -- >> ----------------------------------------- >> Gunnar Hellstr=F6m >> Omnitor >> >>=20 >> gunnar.hellstrom@omnitor.se><= mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >>=20 >> https://www.ietf.org/mailman/= listinfo/slim >> >> >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> Never knock the way the other cat swings. >> --Neal Cassady >> >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >>=20 >> https://www.ietf.org/mailman/= listinfo/slim >> > > > _______________________________________________ > 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: --------------- [Some] billionaires [are] coming together under the leadership of Warren Buffet and Bill Gates to donate their fortunes to worthy causes.... But the billionaires with the strongest sense of class solidarity have an- other plan for their disposable income: activating their lobbyists in Washington, building grassroots movements to march on their behalf, and using their media properties to run experiments on human credulity. --From the essay "Service Disobedience" by Thomas Frank in the February 2011 Harper's Magazine column "Easy Chair." From nobody Fri Dec 1 16:16:19 2017 Return-Path: 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 45D14127078 for ; Fri, 1 Dec 2017 16:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=ntlworld.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 nb2UJhJFoeB3 for ; Fri, 1 Dec 2017 16:16:14 -0800 (PST) Received: from know-smtprelay-omc-2.server.virginmedia.net (know-smtprelay-omc-2.server.virginmedia.net [80.0.253.66]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD052124E15 for ; Fri, 1 Dec 2017 16:16:13 -0800 (PST) Received: from [192.168.0.10] ([81.97.229.170]) by know-smtprelay-2-imp with bizsmtp id goG91w00c3hDt9d01oGA07; Sat, 02 Dec 2017 00:16:11 +0000 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.1 cv=C4wUsl7+ c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=2XxDvuMUAAAA:8 a=48vgC7mUAAAA:8 a=iylOpB4blVspMWrDtuQA:9 a=QEXdDO2ut3YA:10 a=IfFLB24aErD9igj8xSD1:22 a=w1C3t2QeGrPiZgrLijVG:22 To: slim@ietf.org References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> From: Keith Drage Message-ID: Date: Sat, 2 Dec 2017 00:16:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1512173771; bh=zfJYbo8GHsSE1eo0tBfGUQkAgGFuqJieV8H9skB2kOM=; h=Subject:To:References:From:Date:In-Reply-To; b=S2fryqUR2JadrMZbYUkmf1Xyk4Aa1Tfs4gabJ8b9mbBdOyuycJHTs8f0JbdlUAYsv bMfcbSfmbMsXVzOq5jZjYSh+PuguCnFfYj1hZ2dqWfP4OYxAgcKsWGdYgg1JqSznk1 mu70sr45ShNgJCo2qKpwJ51DGKy6bpcI9a2ZpVfkwtC4WJzIDFGZy+x8KAal4zBPc0 ZLQ/pGa1mHSN59mGQPt2lrYyP+ns14vupNXSDnKfsZNEfWACnOm19mGlXjzuOOaniC gWy59Li2qoHsDHZFS1OMa+05Hc5Cx+BQx918/KbmnXECcaPU6Rv1wU555ERumH/7yb WAhGSQ6hJhTuA== Archived-At: Subject: Re: [Slim] Proposed 5.4 text X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2017 00:16:18 -0000 "Non" can only be followed by a hyphen. However the hyphen relates it to the imediately following the word, rather than any sequence of following words. Therefore syntactically you are talking about a "non-sign", which is meaningless. I gave hints in my mail to more appropriate English. Keith On 01-Dec-17 11:17 PM, Randall Gellens wrote: > Hi Keith, > > The document uses the terms "sign language tag" and "non-sign language > tag", both terms applying to language tags.  Neither term is used in > the absence of a tag.  The two terms are defined in Section 5.4.  I do > not see why use of the terms is unclear or harmful, much less > "entirely meaningless."  Along these lines, I don't see how the use of > the "non-" prefix elsewhere is confusing or unclear; this is a very > common prefix to use in Internet Drafts and RFCs. > > --Randall > > At 8:39 PM +0000 11/22/17, Keith Drage wrote: > >>  Why do we keep having to use this construct "non-sign", which in >> itself is entirely meaningless. Surely in this case we are talking >> about a either the absence of a language tag, or the absence of "sgn" >> within a language tag. Why don't we just talk about the absence of >> "sgn" where necessary. >> >>  As an aside I note elsewhere in the document we talk about >> "non-emergency calls", which should mean "a call for a >> non-emergency". The correct opposite to emergency call would be "call >> that is not related to an emergency". >> >>  There are several other "non-" instances in the document that are >> equally meaningless. I assume "non-realtime xxx" is not intended to >> mean "unrealtime xxx", but rather, "xxx that is not realtime". >> >>  Keith >> >>  On 22-Nov-17 2:17 AM, Bernard Aboba wrote: >> >>>  Looks good to me. >>> >>>  On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens >>> <rg+ietf@randy.pensive.org> wrote: >>> >>>  I agree.  I made a few minor editorial changes (e.g., moving some >>> text to a new paragraph): >>> >>>  5.4.  Usage Notes >>> >>>     A sign language tag with a video media stream is interpreted as an >>>     indication for sign language in the video stream.  A non-sign >>>     language tag with a text media stream is interpreted as an >>>     indication for written language in the text stream.  A non-sign >>>     language tag with an audio media stream is interpreted as an >>>     indication for spoken language in the audio stream. >>> >>>     This document does not define any other use for language tags in >>>     video media (such as how to indicate visible captions in the video >>>     stream). >>> >>>     In the IANA registry of language subtags per BCP 47 [RFC5646], a >>>     language subtag with a Type field "extlang" combined with a Prefix >>>     field value "sgn" indicates a sign language tag.  The absense of >>>     such "sgn" prefix indicates a non-sign language tag. >>> >>>     This document does not define the use of sign language tags in text >>>     or audio media. >>> >>>     This document does not define the use of language tags in media >>>     other than interactive streams of audio, video, and text (such as >>>     "message" or "application").  Such use could be supported by future >>>     work or by application agreement. >>> >>> >>>  At 11:50 PM +0100 11/21/17, Gunnar Hellström wrote: >>> >>>   Den 2017-11-21 kl. 23:08, skrev Randall Gellens: >>> >>>   Based on the text and comments from Gunnar, brian, Paul, and >>> Bernard, here is what I propose to replace section 5.4 with: >>> >>>   5.4. Usage Notes >>> >>>   A sign language tag with a video stream is interpreted as an >>>   indication for sign language in the video stream. A non-sign >>>   language tag with text media is interpreted as an indication for >>>   written language. A non-sign language tag with audio media is >>>   interpreted as an indication for spoken language. >>> >>>   In the IANA registry of language subtags per BCP 47 [RFC5646], a >>>   language subtag with a Type field "extlang" combined with a Prefix >>>   field value "sgn" indicates a sign language tag. The absense of >>>   such "sgn" prefix indicates a non-sign language tag. This document >>>   does not define any other use for language tags in video media >>>   (such as how to indicate visible captions). >>> >>>   This document does not define the use of sign language tags in text >>>   or audio media. >>> >>>   This document does not define the use of language tags in media >>>   other than interactive streams of audio, video, and text (such as >>>   "message" or "application"). >>> >>>   Good, I hope that "non-sign language" can be an accepted term. >>>   I provide a slightly modified 5.4 proposal, with a bit more >>> consistent language in the first paragraph, and the mentioning of >>> further work or application agreement reinserted. I think that is >>> better than just saying that it is not defined. I also added the >>> spoken language in video is a view of a speaker according to recent >>> discussion in another mail. >>>   I really hope to find that we are converging now. >>> >>>   ------------------------------new text >>> ------------------------------------------- >>>   5.4 Media, Language and Modality indications >>> >>>   A sign language tag with video media is interpreted as an >>>   indication for sign language in the video stream. A non-sign >>>   language tag with text media is interpreted as an indication for >>>   written language. A non-sign language tag with audio media is >>>   interpreted as an indication for spoken language. A non-sign >>>   language tag with video media is interpreted as a view of a >>>   speaking person. This document does not define any other >>>   use for language tags in video media (such as how to indicate >>>   visible captions in the video stream). >>> >>>   In the IANA registry of language subtags per BCP 47 [RFC5646], a >>>   language subtag with a Type field "extlang" combined with a Prefix >>>   field value "sgn" indicates a sign language tag. The absense of >>>   such "sgn" prefix indicates a non-sign language tag. >>> >>>   This document does not define the use of sign language tags in text >>>   or audio media. This document does not define the use of language >>> tags in media >>>   other than interactive streams of audio, video, and text (such as >>>   "message" or "application"). Such use may be supported by further >>> work >>>   or application specific agreements. >>> >>> >>> >>> --------------------------------------------------------------------------------------------- >>> >>>   Gunnar >>>   -- >>>   ----------------------------------------- >>>   Gunnar Hellström >>>   Omnitor >>> >>> >>> gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se >>> >>>   +46 708 204 288 >>> >>>   _______________________________________________ >>>   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: --------------- >>>  Never knock the way the other cat swings. >>>                           --Neal Cassady >>> >>> >>> >>> >>>  _______________________________________________ >>>  SLIM mailing list >>>  SLIM@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/slim >>> >>> >> >> >>  _______________________________________________ >>  SLIM mailing list >>  SLIM@ietf.org >>  https://www.ietf.org/mailman/listinfo/slim > > From nobody Fri Dec 1 16:39:11 2017 Return-Path: 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 2E40612726E for ; Fri, 1 Dec 2017 16:39:09 -0800 (PST) X-Quarantine-ID: 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.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bJKZiSsPyVzY for ; Fri, 1 Dec 2017 16:39:06 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 87D39120046 for ; Fri, 1 Dec 2017 16:39:06 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 1 Dec 2017 16:39:17 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> X-Mailer: Eudora for Mac OS X Date: Fri, 1 Dec 2017 16:39:02 -0800 To: Keith Drage , slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Slim] Proposed 5.4 text X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2017 00:39:09 -0000 Hi Keith, The RFC Editor may decide to leave it or use two=20 hyphens ("non-sign-language tag"). --Randall At 12:16 AM +0000 12/2/17, Keith Drage wrote: > "Non" can only be followed by a hyphen. However=20 > the hyphen relates it to the imediately=20 > following the word, rather than any sequence of=20 > following words. > > Therefore syntactically you are talking about a=20 > "non-sign", which is meaningless. > > I gave hints in my mail to more appropriate English. > > Keith > > On 01-Dec-17 11:17 PM, Randall Gellens wrote: >> Hi Keith, >> >> The document uses the terms "sign language=20 >> tag" and "non-sign language tag", both terms=20 >> applying to language tags. Neither term is=20 >> used in the absence of a tag. The two terms=20 >> are defined in Section 5.4. I do not see why=20 >> use of the terms is unclear or harmful, much=20 >> less "entirely meaningless." Along these=20 >> lines, I don't see how the use of the "non-"=20 >> prefix elsewhere is confusing or unclear; this=20 >> is a very common prefix to use in Internet=20 >> Drafts and RFCs. >> >> --Randall >> >> At 8:39 PM +0000 11/22/17, Keith Drage wrote: >> >>> Why do we keep having to use this construct=20 >>> "non-sign", which in itself is entirely=20 >>> meaningless. Surely in this case we are=20 >>> talking about a either the absence of a=20 >>> language tag, or the absence of "sgn" within=20 >>> a language tag. Why don't we just talk about=20 >>> the absence of "sgn" where necessary. >>> >>> As an aside I note elsewhere in the document=20 >>> we talk about "non-emergency calls", which=20 >>> should mean "a call for a non-emergency". The=20 >>> correct opposite to emergency call would be=20 >>> "call that is not related to an emergency". >>> >>> There are several other "non-" instances in=20 >>> the document that are equally meaningless. I=20 >>> assume "non-realtime xxx" is not intended to=20 >>> mean "unrealtime xxx", but rather, "xxx that=20 >>> is not realtime". >>> >>> Keith >>> >>> On 22-Nov-17 2:17 AM, Bernard Aboba wrote: >>> >>>> Looks good to me. >>>> >>>> On Tue, Nov 21, 2017 at 3:17 PM, Randall=20 >>>> Gellens=20 >>>> <rg+ietf@randy.pensive.org>=20 >>>> wrote: >>>> >>>> I agree. I made a few minor editorial=20 >>>> changes (e.g., moving some text to a new=20 >>>> paragraph): >>>> >>>> 5.4. Usage Notes >>>> >>>> A sign language tag with a video media stream is interpreted as an >>>> indication for sign language in the video stream. A non-sign >>>> language tag with a text media stream is interpreted as an >>>> indication for written language in the text stream. A non-sign >>>> language tag with an audio media stream is interpreted as an >>>> indication for spoken language in the audio stream. >>>> >>>> This document does not define any other use for language tags in >>>> video media (such as how to indicate visible captions in the video >>>> stream). >>>> >>>> In the IANA registry of language subtags per BCP 47 [RFC5646], a >>>> language subtag with a Type field "extlang" combined with a Prefix >>>> field value "sgn" indicates a sign language tag. The absense of >>>> such "sgn" prefix indicates a non-sign language tag. >>>> >>>> This document does not define the use of sign language tags in tex= t >>>> or audio media. >>>> >>>> This document does not define the use of language tags in media >>>> other than interactive streams of audio, video, and text (such as >>>> "message" or "application"). Such use could be supported by futur= e >>>> work or by application agreement. >>>> >>>> >>>> At 11:50 PM +0100 11/21/17, Gunnar Hellstr=F6m wrote: >>>> >>>> Den 2017-11-21 kl. 23:08, skrev Randall Gellens: >>>> >>>> Based on the text and comments from=20 >>>> Gunnar, brian, Paul, and Bernard, here is=20 >>>> what I propose to replace section 5.4 with: >>>> >>>> 5.4. Usage Notes >>>> >>>> A sign language tag with a video stream is interpreted as an >>>> indication for sign language in the video stream. A non-sign >>>> language tag with text media is interpreted as an indication for >>>> written language. A non-sign language tag with audio media is >>>> interpreted as an indication for spoken language. >>>> >>>> In the IANA registry of language subtags per BCP 47 [RFC5646], a >>>> language subtag with a Type field "extlang" combined with a Prefix >>>> field value "sgn" indicates a sign language tag. The absense of >>>> such "sgn" prefix indicates a non-sign language tag. This document >>>> does not define any other use for language tags in video media >>>> (such as how to indicate visible captions). >>>> >>>> This document does not define the use of sign language tags in text >>>> or audio media. >>>> >>>> This document does not define the use of language tags in media >>>> other than interactive streams of audio, video, and text (such as >>>> "message" or "application"). >>>> >>>> Good, I hope that "non-sign language" can be an accepted term. >>>> I provide a slightly modified 5.4=20 >>>> proposal, with a bit more consistent=20 >>>> language in the first paragraph, and the=20 >>>> mentioning of further work or application=20 >>>> agreement reinserted. I think that is better=20 >>>> than just saying that it is not defined. I=20 >>>> also added the spoken language in video is a=20 >>>> view of a speaker according to recent=20 >>>> discussion in another mail. >>>> I really hope to find that we are converging now. >>>> >>>> ------------------------------new text=20 >>>> ------------------------------------------- >>>> 5.4 Media, Language and Modality indications >>>> >>>> A sign language tag with video media is interpreted as an >>>> indication for sign language in the video stream. A non-sign >>>> language tag with text media is interpreted as an indication for >>>> written language. A non-sign language tag with audio media is >>>> interpreted as an indication for spoken language. A non-sign >>>> language tag with video media is interpreted as a view of a >>>> speaking person. This document does not define any other >>>> use for language tags in video media (such as how to indicate >>>> visible captions in the video stream). >>>> >>>> In the IANA registry of language subtags per BCP 47 [RFC5646], a >>>> language subtag with a Type field "extlang" combined with a Prefix >>>> field value "sgn" indicates a sign language tag. The absense of >>>> such "sgn" prefix indicates a non-sign language tag. >>>> >>>> This document does not define the use of sign language tags in text >>>> or audio media. This document does not=20 >>>> define the use of language tags in media >>>> other than interactive streams of audio, video, and text (such as >>>> "message" or "application"). Such use may be supported by further wo= rk >>>> or application specific agreements. >>>> >>>> >>>> >>>>=20 >>>> -----------------------------------------------------------------------= ---------------------- >>>> Gunnar >>>> -- >>>> ----------------------------------------- >>>> Gunnar Hellstr=F6m >>>> Omnitor >>>> >>>> >>>>=20 >>>> gunnar.hellstrom@omnitor.se= >gunnar.hellstrom@omnitor.se >>>> +46 708 204 288 >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> >>>>=20 >>>> https://www.ietf.org/mailma= n/listinfo/slim >>>> >>>> >>>> >>>> -- >>>> Randall Gellens >>>> Opinions are personal; facts are suspect; I speak for myself on= ly >>>> -------------- Randomly selected tag: --------------- >>>> Never knock the way the other cat swings. >>>> --Neal Cassady >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> SLIM mailing list >>>> SLIM@ietf.org >>>> >>>>=20 >>>> https://www.ietf.org/mailma= n/listinfo/slim >>>> >>> >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim >> >> > > _______________________________________________ > 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: --------------- ondinnonk (ON-din-onk; Iroquoian; noun): the soul's innermost benevolent desires. From nobody Sun Dec 3 02:42:22 2017 Return-Path: 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 296201241FC for ; Sun, 3 Dec 2017 02:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 g79CV1CkA0Kn for ; Sun, 3 Dec 2017 02:42:17 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D4C120713 for ; Sun, 3 Dec 2017 02:42:17 -0800 (PST) X-Halon-ID: 9a8d0aed-d816-11e7-811e-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.159.245]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 9a8d0aed-d816-11e7-811e-0050569116f7; Sun, 03 Dec 2017 11:42:05 +0100 (CET) To: Keith Drage , slim@ietf.org References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <93ec6be8-1ced-e6da-3693-6cf66069c50c@omnitor.se> Date: Sun, 3 Dec 2017 11:42:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> Content-Type: multipart/alternative; boundary="------------34D08F4B1E589ED1085780C6" Content-Language: en-US Archived-At: Subject: Re: [Slim] Proposed 5.4 text X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 10:42:21 -0000 This is a multi-part message in MIME format. --------------34D08F4B1E589ED1085780C6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Keith, Continuing the discussion of "non-sign": Den 2017-11-22 kl. 21:39, skrev Keith Drage: > Why do we keep having to use this construct "non-sign", which in > itself is entirely meaningless. Surely in this case we are talking > about a either the absence of a language tag, or the absence of "sgn" > within a language tag. Why don't we just talk about the absence of > "sgn" where necessary. We are talking about languages that are not signed. That is spoken or written. We tried to use the term "spoken/written language" for them, but got opposition from language experts. The end users need to know what modality to use that fits the negotiation. We have realized that also the devices and network components could sometimes have benefit of "knowing" the intended modality. So it is appropriate to tell how to handle signed languages versus non-signed languages. The "sgn" is a language tag prefix that is usually not accompanying the language tag when it is sent, but can be found in a separate entry for the language in the language tag registry. Talking about the absence of "sgn" within the language tag is therefore not correct and we have therefore included the description of how to find out if a language is a sign language or not. When we needed to move away from using "spoken/written language", the replacement "non-sign language" was proposed. I think it expresses what we need, but there are certainly other ways to express the same thing. Randall proposed that if we cannot keep "non-sign language", we could change it to "non-sign-language" to more clearly indicate that we talk about a language that is not a sign language. I I also thought about using "non-signed language". That matches well the modality indicated in "spoken language" and "written language". The term "signed language" is used intermixed with "sign language" in both RFC 5646 and our draft and elsewhere. Other constructs are possible, but easily get complex. Here is one possible example using the term "tag for a language that is not signed" instead of "non-sign language tag" --------------------------current wording in 5.4-------------------------- A sign language tag with a video media stream is interpreted as an indication for sign language in the video stream. A non-sign language tag with a text media stream is interpreted as an indication for written language in the text stream. A non-sign language tag with an audio media stream is interpreted as an indication for spoken language in the audio stream. This document does not define any other use for language tags in video media (such as how to indicate visible captions in the video stream). In the IANA registry of language subtags perBCP 47 [RFC5646 ], a language subtag with a Type field "extlang" combined with a Prefix field value "sgn" indicates a sign language tag. The absense of such "sgn" prefix indicates a non-sign language tag. --------------------possible new wording - but not my favourite proposal--------------- A sign language tag with a video media stream is interpreted as an indication for sign language in the video stream. A language tag for a language that is not signed, used with a text media stream is interpreted as an indication for written language in the text stream. A language tag for a language  that is not signed, used with an audio media stream is interpreted as an indication for spoken language in the audio stream. This document does not define any other use for language tags in video media (such as how to indicate visible captions in the video stream). In the IANA registry of language subtags perBCP 47 [RFC5646 ], a language subtag with a Type field "extlang" combined with a Prefix field value "sgn" indicates a sign language tag. The absence of such "sgn" prefix indicates a language tag for a language that is not signed. -------------------------------------------------------------------------------- So, what do we prefer: 1. Leave "non-sign" as is. 2. Replace "non-sign language" with "non-sign-language". 3. Replace "non-sign" with "non-signed" 4. Replace "non-sign language tag" with "language tag for a language that is not signed" I can accept any of these, but have a slight preference for #3, "non-signed". > > As an aside I note elsewhere in the document we talk about > "non-emergency calls", which should mean "a call for a non-emergency". > The correct opposite to emergency call would be "call that is not > related to an emergency". > > There are several other "non-" instances in the document that are > equally meaningless. I assume "non-realtime xxx" is not intended to > mean "unrealtime xxx", but rather, "xxx that is not realtime". I think these are sufficiently often used in other RFCs to be understood. Gunnar > > Keith > > On 22-Nov-17 2:17 AM, Bernard Aboba wrote: >> Looks good to me. >> >> On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens >> > wrote: >> >> I agree.  I made a few minor editorial changes (e.g., moving some >> text to a new paragraph): >> >> 5.4.  Usage Notes >> >>    A sign language tag with a video media stream is interpreted as an >>    indication for sign language in the video stream.  A non-sign >>    language tag with a text media stream is interpreted as an >>    indication for written language in the text stream.  A non-sign >>    language tag with an audio media stream is interpreted as an >>    indication for spoken language in the audio stream. >> >>    This document does not define any other use for language tags in >>    video media (such as how to indicate visible captions in the video >>    stream). >> >>    In the IANA registry of language subtags per BCP 47 [RFC5646], a >>    language subtag with a Type field "extlang" combined with a Prefix >>    field value "sgn" indicates a sign language tag.  The absense of >>    such "sgn" prefix indicates a non-sign language tag. >> >>    This document does not define the use of sign language tags in >> text >>    or audio media. >> >>    This document does not define the use of language tags in media >>    other than interactive streams of audio, video, and text (such as >>    "message" or "application").  Such use could be supported by >> future >>    work or by application agreement. >> >> >> At 11:50 PM +0100 11/21/17, Gunnar Hellström wrote: >> >>  Den 2017-11-21 kl. 23:08, skrev Randall Gellens: >> >>  Based on the text and comments from Gunnar, brian, Paul, >> and Bernard, here is what I propose to replace section >> 5.4 with: >> >>  5.4. Usage Notes >> >>  A sign language tag with a video stream is interpreted as an >>  indication for sign language in the video stream. A non-sign >>  language tag with text media is interpreted as an >> indication for >>  written language. A non-sign language tag with audio >> media is >>  interpreted as an indication for spoken language. >> >>  In the IANA registry of language subtags per BCP 47 >> [RFC5646], a >>  language subtag with a Type field "extlang" combined >> with a Prefix >>  field value "sgn" indicates a sign language tag. The >> absense of >>  such "sgn" prefix indicates a non-sign language tag. >> This document >>  does not define any other use for language tags in video >> media >>  (such as how to indicate visible captions). >> >>  This document does not define the use of sign language >> tags in text >>  or audio media. >> >>  This document does not define the use of language tags >> in media >>  other than interactive streams of audio, video, and text >> (such as >>  "message" or "application"). >> >>   Good, I hope that "non-sign language" can be an >> accepted term. >>  I provide a slightly modified 5.4 proposal, with a bit more >> consistent language in the first paragraph, and the >> mentioning of further work or application agreement >> reinserted. I think that is better than just saying that it >> is not defined. I also added the spoken language in video is >> a view of a speaker according to recent discussion in another >> mail. >>  I really hope to find that we are converging now. >> >>  ------------------------------new text >> ------------------------------------------- >>  5.4 Media, Language and Modality indications >> >>  A sign language tag with video media is interpreted as an >>  indication for sign language in the video stream. A non-sign >>  language tag with text media is interpreted as an indication for >>  written language. A non-sign language tag with audio media is >>  interpreted as an indication for spoken language. A non-sign >>  language tag with video media is interpreted as a view of a >>  speaking person. This document does not define any other >>  use for language tags in video media (such as how to indicate >>  visible captions in the video stream). >> >>  In the IANA registry of language subtags per BCP 47 [RFC5646], a >>  language subtag with a Type field "extlang" combined with a >> Prefix >>  field value "sgn" indicates a sign language tag. The absense of >>  such "sgn" prefix indicates a non-sign language tag. >> >>  This document does not define the use of sign language tags >> in text >>  or audio media. This document does not define the use of >> language tags in media >>  other than interactive streams of audio, video, and text >> (such as >>  "message" or "application"). Such use may be supported by >> further work >>  or application specific agreements. >> >> >> --------------------------------------------------------------------------------------------- >>  Gunnar >>  -- >>  ----------------------------------------- >>  Gunnar Hellström >>  Omnitor >>  > >gunnar.hellstrom@omnitor.se >> >> +46 708 204 288 >> >>  _______________________________________________ >>  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: --------------- >> Never knock the way the other cat swings. >>                          --Neal Cassady >> >> >> >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim > > > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------34D08F4B1E589ED1085780C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Keith,

Continuing the discussion of "non-sign":

Den 2017-11-22 kl. 21:39, skrev Keith Drage:
Why do we keep having to use this construct "non-sign", which in itself is entirely meaningless. Surely in this case we are talking about a either the absence of a language tag, or the absence of "sgn" within a language tag. Why don't we just talk about the absence of "sgn" where necessary.
We are talking about languages that are not signed. That is spoken or written. We tried to use the term "spoken/written language" for them, but got opposition from language experts. The end users need to know what modality to use that fits the negotiation. We have realized that also the devices and network components could sometimes have benefit of "knowing" the intended modality. So it is appropriate to tell how to handle signed languages versus non-signed languages. The "sgn" is a language tag prefix that is usually not accompanying the language tag when it is sent, but can be found in a separate entry for the language in the language tag registry. Talking about the absence of "sgn" within the language tag is therefore not correct and we have therefore included the description of how to find out if a language is a sign language or not.

When we needed to move away from using "spoken/written language", the replacement "non-sign language" was proposed. I think it expresses what we need, but there are certainly other ways to express the same thing.

Randall proposed that if we cannot keep "non-sign language", we could change it to "non-sign-language" to more clearly indicate that we talk about a language that is not a sign language. I

I also thought about using "non-signed language". That matches well the modality indicated in "spoken language" and "written language". The term "signed language" is used intermixed with "sign language" in both RFC 5646 and our draft and elsewhere.

Other constructs are possible, but easily get complex. Here is one possible example using the term "tag for a language that is not signed" instead of "non-sign language tag"
--------------------------current wording in 5.4--------------------------
 A sign language tag with a video media stream is interpreted as an
   indication for sign language in the video stream.  A non-sign
   language tag with a text media stream is interpreted as an indication
   for written language in the text stream.  A non-sign language tag
   with an audio media stream is interpreted as an indication for spoken
   language in the audio stream.

   This document does not define any other use for language tags in
   video media (such as how to indicate visible captions in the video
   stream).

   In the IANA registry of language subtags per BCP 47 [RFC5646], a
   language subtag with a Type field "extlang" combined with a Prefix
   field value "sgn" indicates a sign language tag.  The absense of such
   "sgn" prefix indicates a non-sign language tag.



--------------------possible new wording - but not my favourite proposal---------------
   A sign language tag with a video media stream is interpreted as an
   indication for sign language in the video stream.  A
   language tag for a language that is not signed, used with a text 
   media stream is interpreted as an indication
   for written language in the text stream.  A language tag for a language
   that is not signed, used
   with an audio media stream is interpreted as an indication for spoken
   language in the audio stream.

   This document does not define any other use for language tags in
   video media (such as how to indicate visible captions in the video
   stream).

   In the IANA registry of language subtags per BCP 47 [RFC5646], a
   language subtag with a Type field "extlang" combined with a Prefix
   field value "sgn" indicates a sign language tag.  The absence of such
   "sgn" prefix indicates a language tag for a language that is not signed.
--------------------------------------------------------------------------------

So, what do we prefer:

1. Leave "non-sign" as is.

2. Replace "non-sign language" with "non-sign-language".

3. Replace "non-sign" with "non-signed"

4. Replace "non-sign language tag" with "language tag for a language that is not signed"

I can accept any of these, but have a slight preference for #3, "non-signed".


 

As an aside I note elsewhere in the document we talk about "non-emergency calls", which should mean "a call for a non-emergency". The correct opposite to emergency call would be "call that is not related to an emergency".

There are several other "non-" instances in the document that are equally meaningless. I assume "non-realtime xxx" is not intended to mean "unrealtime xxx", but rather, "xxx that is not realtime".
<GH>I think these are sufficiently often used in other RFCs to be understood.

Gunnar

Keith

On 22-Nov-17 2:17 AM, Bernard Aboba wrote:
Looks good to me. 

On Tue, Nov 21, 2017 at 3:17 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
I agree.  I made a few minor editorial changes (e.g., moving some text to a new paragraph):

5.4.  Usage Notes

   A sign language tag with a video media stream is interpreted as an
   indication for sign language in the video stream.  A non-sign
    language tag with a text media stream is interpreted as an
   indication for written language in the text stream.  A non-sign
   language tag with an audio media stream is interpreted as an
   indication for spoken language in the audio stream.

   This document does not define any other use for language tags in
   video media (such as how to indicate visible captions in the video
   stream).

   In the IANA registry of language subtags per BCP 47 [RFC5646], a
   language subtag with a Type field "extlang" combined with a Prefix
   field value "sgn" indicates a sign language tag.  The absense of
   such "sgn" prefix indicates a non-sign language tag.

   This document does not define the use of sign language tags in text
   or audio media.

   This document does not define the use of language tags in media
   other than interactive streams of audio, video, and text (such as
    "message" or "application").  Such use could be supported by future
   work or by application agreement.


At 11:50 PM +0100 11/21/17, Gunnar Hellström wrote:

 Den 2017-11-21 kl. 23:08, skrev Randall Gellens:

 Based on the text and comments from Gunnar, brian, Paul, and Bernard, here is what I propose to replace section 5.4 with:

 5.4. Usage Notes

 A sign language tag with a video stream is interpreted as an
 indication for sign language in the video stream. A non-sign
 language tag with text media is interpreted as an indication for
 written language. A non-sign language tag with audio media is
 interpreted as an indication for spoken language.

 In the IANA registry of language subtags per BCP 47 [RFC5646], a
 language subtag with a Type field "extlang" combined with a Prefix
 field value "sgn" indicates a sign language tag. The absense of
 such "sgn" prefix indicates a non-sign language tag. This document
 does not define any other use for language tags in video media
 (such as how to indicate visible captions).

 This document does not define the use of sign language tags in text
 or audio media.

 This document does not define the use of language tags in media
 other than interactive streams of audio, video, and text (such as
 "message" or "application").

 <GH> Good, I hope that "non-sign language" can be an accepted term.
 I provide a slightly modified 5.4 proposal, with a bit more consistent language in the first paragraph, and the mentioning of further work or application agreement reinserted. I think that is better than just saying that it is not defined. I also added the spoken language in video is a view of a speaker according to recent discussion in another mail.
 I really hope to find that we are converging now.

 ------------------------------new text -------------------------------------------
 5.4 Media, Language and Modality indications

 A sign language tag with video media is interpreted as an
 indication for sign language in the video stream. A non-sign
 language tag with text media is interpreted as an indication for
 written language. A non-sign language tag with audio media is
 interpreted as an indication for spoken language. A non-sign
 language tag with video media is interpreted as a view of a
 speaking person. This document does not define any other
 use for language tags in video media (such as how to indicate
 visible captions in the video stream).

 In the IANA registry of language subtags per BCP 47 [RFC5646], a
 language subtag with a Type field "extlang" combined with a Prefix
 field value "sgn" indicates a sign language tag. The absense of
 such "sgn" prefix indicates a non-sign language tag.

 This document does not define the use of sign language tags in text
 or audio media. This document does not define the use of language tags in media
 other than interactive streams of audio, video, and text (such as
 "message" or "application"). Such use may be supported by further work
 or application specific agreements.


---------------------------------------------------------------------------------------------
 Gunnar
 --
 -----------------------------------------
 Gunnar Hellström
 Omnitor
 <mailto:gunnar.hellstrom@omnitor.se>gunnar.hellstrom@omnitor.se
 +46 708 204 288

 _______________________________________________
 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: ---------------
 Never knock the way the other cat swings.
                         --Neal Cassady



_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim





_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------34D08F4B1E589ED1085780C6-- From nobody Tue Dec 5 11:27:58 2017 Return-Path: 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 EE9AB126DCA for ; Tue, 5 Dec 2017 11:27:56 -0800 (PST) X-Quarantine-ID: 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 DgAKDbNePFhB for ; Tue, 5 Dec 2017 11:27:55 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B2CEF126C2F for ; Tue, 5 Dec 2017 11:27:55 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 5 Dec 2017 11:28:09 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <93ec6be8-1ced-e6da-3693-6cf66069c50c@omnitor.se> References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> <93ec6be8-1ced-e6da-3693-6cf66069c50c@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Tue, 5 Dec 2017 11:27:53 -0800 To: slim@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] Proposed 5.4 text X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 19:27:57 -0000 The argument over the use of "non-" is pointless and a waste of time. We should not keep reopening it. The draft clear and unambiguous. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It is not enough to write in Yiddish; one must have something to say. --Y.L. Peretz From nobody Tue Dec 5 14:29:55 2017 Return-Path: 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 1F74D1277BB for ; Tue, 5 Dec 2017 14:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 QsidRXdklmqP for ; Tue, 5 Dec 2017 14:29:51 -0800 (PST) Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B90126B6D for ; Tue, 5 Dec 2017 14:29:50 -0800 (PST) X-Halon-ID: befd81f1-da0b-11e7-aafb-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.159.245]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id befd81f1-da0b-11e7-aafb-005056917a89; Tue, 05 Dec 2017 23:29:24 +0100 (CET) To: slim@ietf.org References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> <93ec6be8-1ced-e6da-3693-6cf66069c50c@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <920ae4bc-0c0b-d571-4b9b-bdc2b08bba4b@omnitor.se> Date: Tue, 5 Dec 2017 23:29:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Slim] Proposed 5.4 text X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 22:29:53 -0000 Den 2017-12-05 kl. 20:27, skrev Randall Gellens: > The argument over the use of "non-" is pointless and a waste of time. > We should not keep reopening it.  The draft clear and unambiguous. I tend to agree. I provided four alternatives in order to try to reach consensus: 1. Leave "non-sign" as is. 2. Replace "non-sign language" with "non-sign-language". 3. Replace "non-sign" with "non-signed" 4. Replace "non-sign language tag" with "language tag for a language that is not signed" I can accept any of these, but have myself a slight preference for #3, "non-signed". Now, since Randall still prefers #1, I suggest that we close the issue with the conclusion that we keep it as it is in -19. Regards Gunnar -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 From nobody Tue Dec 5 17:21:20 2017 Return-Path: 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 078A8127735 for ; Tue, 5 Dec 2017 17:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 atuj4HzwWxsq for ; Tue, 5 Dec 2017 17:21:18 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 15D00124217 for ; Tue, 5 Dec 2017 17:21:18 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id v20so1750140uaj.0 for ; Tue, 05 Dec 2017 17:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xaxk7a/wIiqDZlOO3N4LaBIZzB6OHyGmTVaGqSe2Z0g=; b=Figtj9UvMRi0VqTXHcdjWhdZVDbvhgYrW67TyXgm3TE5ecBMZvzJHLnA9vaOP+Dh1Z mENK/ASIP6/ItsEBTPVCz5rywpiXRS+1mB9MCPDHvvyRfYlsuLdlOgiP3dlspoSGBxSF ct7tPaYDiOlRI78d3kD+LD/5bLEtwWANoyHJ5v+LQQD6168WrBTgLPHL87imaZrpGVYV ArJbNJxnk5MyahD0+gWNOnHw7X36RZJcO7jMTDvghYawH7CP2bln8EwV3S2iXbQL0Q25 TlfdKfL3nkkuqnfx++J7+5+XwMtbKKiOTk40Vrwn3SWChZuJjRDe2HawvSL62IHfIMNJ y8Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xaxk7a/wIiqDZlOO3N4LaBIZzB6OHyGmTVaGqSe2Z0g=; b=r04w0jwaAOP9zzHBY0AcwpehPo0TOx3tCM0rvI+FqK8DM18eYEQLXqhoEZaowoGOtU ch3BatCq79zhG6YWxoZGNVw5EVt2LlQBJvgjKsWjwmQhtjXyDc7gQZZYF/kIM6Ep2Nom pdf7gLmK5Sgdbx5enBBAXaXhYfXJ7RZIPobOtMZRBDAa1gR9cVs1DdJ5s0oGtfHZjfnU q2X4t56Kdv0jcIF3nvmrkjkk8VUnBwDVEwFTlbXrYPpSQkatEOZJh2C3gf9LeCyoOBgc 3pF1q7+Kwq3AypaH7fM46LbgAZyVkdgG/No42npxC+K123eSv8PL+zN+qkuYhJ/ceV+v 9fug== X-Gm-Message-State: AKGB3mJqxjjAS/LLE+ZNbJTwx40k1H3wNYsyyozOO5/DDFjriLRDwRpe kFKLfl2s6ptyvYSWS3uLBR3xrgDO X-Google-Smtp-Source: AGs4zMZD2HmDPmMIdW8DZszKrsSZpuHl/G2J3/NfuKio5GtfMrF310yiGpC4LKZGmYVg5MtYPfhRlQ== X-Received: by 10.176.23.81 with SMTP id k17mr8123817uaf.131.1512523276841; Tue, 05 Dec 2017 17:21:16 -0800 (PST) Received: from [10.0.1.4] (c-73-138-215-3.hsd1.fl.comcast.net. [73.138.215.3]) by smtp.gmail.com with ESMTPSA id j10sm841085uaf.46.2017.12.05.17.21.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 17:21:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15C114) In-Reply-To: <920ae4bc-0c0b-d571-4b9b-bdc2b08bba4b@omnitor.se> Date: Tue, 5 Dec 2017 20:21:14 -0500 Cc: slim@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2B21087E-D5E1-4817-BD57-6F5E6E6000F1@gmail.com> References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> <93ec6be8-1ced-e6da-3693-6cf66069c50c@omnitor.se> <920ae4bc-0c0b-d571-4b9b-bdc2b08bba4b@omnitor.se> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Archived-At: Subject: Re: [Slim] Proposed 5.4 text X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 01:21:20 -0000 I can live with #1. > On Dec 5, 2017, at 5:29 PM, Gunnar Hellstr=C3=B6m wrote: >=20 >> Den 2017-12-05 kl. 20:27, skrev Randall Gellens: >> The argument over the use of "non-" is pointless and a waste of time. We s= hould not keep reopening it. The draft clear and unambiguous. > I tend to agree. > I provided four alternatives in order to try to reach consensus: >=20 > 1. Leave "non-sign" as is. >=20 > 2. Replace "non-sign language" with "non-sign-language". >=20 > 3. Replace "non-sign" with "non-signed" >=20 > 4. Replace "non-sign language tag" with "language tag for a language that i= s not signed" >=20 > I can accept any of these, but have myself a slight preference for #3, "no= n-signed". >=20 > Now, since Randall still prefers #1, I suggest that we close the issue wit= h the conclusion that we keep it as it is in -19. >=20 > Regards >=20 > Gunnar >=20 >=20 >=20 >=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim From nobody Wed Dec 6 02:45:58 2017 Return-Path: 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 C2EB81296CF for ; Wed, 6 Dec 2017 02:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 JCKqUmdx5AEx for ; Wed, 6 Dec 2017 02:45:47 -0800 (PST) Received: from know-smtprelay-omc-9.server.virginmedia.net (know-smtprelay-omc-9.server.virginmedia.net [80.0.253.73]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11569129789 for ; Wed, 6 Dec 2017 02:45:32 -0800 (PST) Received: from [192.168.0.10] ([81.97.229.170]) by know-smtprelay-9-imp with bizsmtp id ialU1w00K3hDt9d01alVfD; Wed, 06 Dec 2017 10:45:30 +0000 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.1 cv=Z+YRZylA c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=iRKYOAB3NpWzKX0jWw4A:9 a=QEXdDO2ut3YA:10 To: slim@ietf.org References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> <93ec6be8-1ced-e6da-3693-6cf66069c50c@omnitor.se> From: Keith Drage Message-ID: Date: Wed, 6 Dec 2017 10:45:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1512557130; bh=iXPFPAVXmfZFcnks8G7Kjb+7O1Xn4TSZAtZv6IgRMHE=; h=Subject:To:References:From:Date:In-Reply-To; b=vDm1amO3cr+21ZB9JmrtyrKLUowqdBHjDA2O7Qt092GyzVIam9jUKqQ2Jh6sF6Kgu OOvnfwHFKIyqWkWp+TEI8tr6TK+PZ1YKADGlHry2nd3PORqXc3gxoEkjKHgPEvUPV5 b8wk+0pQebiyGkKwTyBVDrMAhfegwrgGqOBVmOnX2OT3WcgX11BqSedQCnA/NhSaSf BQ1UFzCzHt4yO3pQuEIXLvxaAg6foQtpsLjGFZKcOvNuXMmP1THnenBuDFvE83Q4lI 0wafc4XxxbhkSXOkgFgNa3q7bfK7yBaGcj0Rz/OR6CoI7H4Dgqiqua7kvcWDDVfInX Z92xoS36MnZhQ== Archived-At: Subject: Re: [Slim] Proposed 5.4 text X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 10:45:57 -0000 Dear Rundell Of course I have spelt your name wrong, but in the context it is unambiguous, and therefore does not matter. Keith On 05-Dec-17 7:27 PM, Randall Gellens wrote: > The argument over the use of "non-" is pointless and a waste of time. > We should not keep reopening it.  The draft clear and unambiguous. > From nobody Wed Dec 6 09:21:49 2017 Return-Path: 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 AED611275FD for ; Wed, 6 Dec 2017 09:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Sryn2MHWixlc for ; Wed, 6 Dec 2017 09:21:44 -0800 (PST) Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D9812778D for ; Wed, 6 Dec 2017 09:21:43 -0800 (PST) X-Halon-ID: de531262-daa9-11e7-aafc-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.159.245]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id de531262-daa9-11e7-aafc-005056917a89; Wed, 06 Dec 2017 18:21:17 +0100 (CET) To: Bernard Aboba Cc: slim@ietf.org References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> <93ec6be8-1ced-e6da-3693-6cf66069c50c@omnitor.se> <920ae4bc-0c0b-d571-4b9b-bdc2b08bba4b@omnitor.se> <2B21087E-D5E1-4817-BD57-6F5E6E6000F1@gmail.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Wed, 6 Dec 2017 18:21:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <2B21087E-D5E1-4817-BD57-6F5E6E6000F1@gmail.com> Content-Type: multipart/alternative; boundary="------------70253C6E701979C9B15921F3" Content-Language: en-US Archived-At: Subject: Re: [Slim] Proposed 5.4 text X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 17:21:47 -0000 This is a multi-part message in MIME format. --------------70253C6E701979C9B15921F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Even if I have said that for me we can close the issue keeping the current wording, I want to explain my view of the wording and test a new proposal. It is the term "non-sign language tag" we discuss. That makes the "tag" to be the main noun, and what is before it can be seen as specifiers for "tag". I get the impression that Keith has seen this and want to make that clear. However, the "non-sign" rather applies to the language. It is for when the language is not a signed language we want to express the conditions for use of the tag. My proposal #4 is intended to make that very clear, but resulted in inconveniently complex wording. I want to try a compromise: "tag for a non-signed language" I use "non-signed" instead or "non-sign" because "non-signed" is used elsewhere while I never saw "non-sign" before. Non-signed is also a self-sustained verb, while I do not really know what "non-sign" is grammatically. That makes a new wording proposal for 5.4 be: ------------------new wording---------------------------------------------------------------- A sign language tag with a video media stream is interpreted as an indication for sign language in the video stream. A tag for a non-signed language with a text media stream is interpreted as an indication for written language in the text stream. A tag for a non-signed language with an audio media stream is interpreted as an indication for spoken language in the audio stream. This document does not define any other use for language tags in video media (such as how to indicate visible captions in the video stream). In the IANA registry of language subtags perBCP 47 [RFC5646 ], a language subtag with a Type field "extlang" combined with a Prefix field value "sgn" indicates a tag for a sign language. The absence of such "sgn" prefix indicates a tag for a non-signed language. ------------------end of new wording---------------------------------------  Is this more acceptable by all? /Gunnar Den 2017-12-06 kl. 02:21, skrev Bernard Aboba: > I can live with #1. > >> On Dec 5, 2017, at 5:29 PM, Gunnar Hellström wrote: >> >>> Den 2017-12-05 kl. 20:27, skrev Randall Gellens: >>> The argument over the use of "non-" is pointless and a waste of time. We should not keep reopening it. The draft clear and unambiguous. >> I tend to agree. >> I provided four alternatives in order to try to reach consensus: >> >> 1. Leave "non-sign" as is. >> >> 2. Replace "non-sign language" with "non-sign-language". >> >> 3. Replace "non-sign" with "non-signed" >> >> 4. Replace "non-sign language tag" with "language tag for a language that is not signed" >> >> I can accept any of these, but have myself a slight preference for #3, "non-signed". >> >> Now, since Randall still prefers #1, I suggest that we close the issue with the conclusion that we keep it as it is in -19. >> >> Regards >> >> Gunnar >> >> >> >> >> -- >> ----------------------------------------- >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46 708 204 288 >> >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------70253C6E701979C9B15921F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Even if I have said that for me we can close the issue keeping the current wording, I want to explain my view of the wording and test a new proposal.

It is the term "non-sign language tag" we discuss.

That makes the "tag" to be the main noun, and what is before it can be seen as specifiers for "tag". I get the impression that Keith has seen this and want to make that clear.

However, the "non-sign" rather applies to the language. It is for when the language is not a signed language we want to express the conditions for use of the tag. My proposal #4 is intended to make that very clear, but resulted in inconveniently complex wording.

I want to try a compromise: "tag for a non-signed language"

I use "non-signed" instead or "non-sign" because "non-signed" is used elsewhere while I never saw "non-sign" before. Non-signed is also a self-sustained verb, while I do not really know what "non-sign" is grammatically.

That makes a new wording proposal for 5.4 be:
------------------new wording----------------------------------------------------------------

 A sign language tag with a video media stream is interpreted as an
   indication for sign language in the video stream.  A tag for a non-signed
   language with a text media stream is interpreted as an indication
   for written language in the text stream.  A tag for a non-signed language
   with an audio media stream is interpreted as an indication for spoken
   language in the audio stream.

   This document does not define any other use for language tags in
   video media (such as how to indicate visible captions in the video
   stream).

   In the IANA registry of language subtags per BCP 47 [RFC5646], a
   language subtag with a Type field "extlang" combined with a Prefix
   field value "sgn" indicates a tag for a sign language.  The absence of such
   "sgn" prefix indicates a tag for a non-signed language.
------------------end of new wording---------------------------------------
 Is this more acceptable by all?

/Gunnar

Den 2017-12-06 kl. 02:21, skrev Bernard Aboba:
I can live with #1.


On Dec 5, 2017, at 5:29 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:


Den 2017-12-05 kl. 20:27, skrev Randall Gellens:
The argument over the use of "non-" is pointless and a waste of time. We should not keep reopening it.  The draft clear and unambiguous.

I tend to agree.
I provided four alternatives in order to try to reach consensus:

1. Leave "non-sign" as is.

2. Replace "non-sign language" with "non-sign-language".

3. Replace "non-sign" with "non-signed"

4. Replace "non-sign language tag" with "language tag for a language that is not signed"

I can accept any of these, but have myself a slight preference for #3, "non-signed".

Now, since Randall still prefers #1, I suggest that we close the issue with the conclusion that we keep it as it is in -19.

Regards

Gunnar




-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------70253C6E701979C9B15921F3-- From nobody Wed Dec 6 12:17:57 2017 Return-Path: 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 B4B40124B09 for ; Wed, 6 Dec 2017 12:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 wOyBz-vQcCQo for ; Wed, 6 Dec 2017 12:17:53 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E476612426E for ; Wed, 6 Dec 2017 12:17:52 -0800 (PST) X-Halon-ID: 82970fc3-dac2-11e7-8120-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.159.245]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 82970fc3-dac2-11e7-8120-0050569116f7; Wed, 06 Dec 2017 21:17:41 +0100 (CET) From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= To: Bernard Aboba Cc: slim@ietf.org References: <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <6812d89a-ba10-0947-5320-07374b8c071d@comcast.net> <72f7975c-91f5-91c2-6d8c-4f66aec63cf9@omnitor.se> <85024248-d22d-6379-6194-fdb17c4c913a@ntlworld.com> <93ec6be8-1ced-e6da-3693-6cf66069c50c@omnitor.se> <920ae4bc-0c0b-d571-4b9b-bdc2b08bba4b@omnitor.se> <2B21087E-D5E1-4817-BD57-6F5E6E6000F1@gmail.com> Message-ID: Date: Wed, 6 Dec 2017 21:17:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8DD2EB97D08B83651AA572EB" Content-Language: en-US Archived-At: Subject: Re: [Slim] Proposed 5.4 text X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 20:17:56 -0000 This is a multi-part message in MIME format. --------------8DD2EB97D08B83651AA572EB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I need to correct my statement that I have not seen the construct . "non-sign language" before. Now I have. A very rough search gave hits where the use is quite similar to how it is used in draft version -19 in a term containing some more words as specifiers to a noun at the end. Example 1: https://www.cio.com/article/2381300/vertical-industries/microsoft-uses-kinect-to-interpret-sign-language-from-deaf-people.html Search for "non-sign", and you will find: "It's thought that the system could help deaf users make presentations to non-sign language speaking crowds." Example 2: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2693477/ Search for "non-sign" and you will find: "Several researchers (Corina et al., 1992 ;Emmorey et al., 2004 ;Marshall and Fink, 2001 ) have established that different neural systems subserve sign language production and non-sign language pantomimic expression." I think that that confirms that the issue can be closed using any of the now 5 solutions I have presented. Gunnar Den 2017-12-06 kl. 18:21, skrev Gunnar Hellström: > > Even if I have said that for me we can close the issue keeping the > current wording, I want to explain my view of the wording and test a > new proposal. > > It is the term "non-sign language tag" we discuss. > > That makes the "tag" to be the main noun, and what is before it can be > seen as specifiers for "tag". I get the impression that Keith has seen > this and want to make that clear. > > However, the "non-sign" rather applies to the language. It is for when > the language is not a signed language we want to express the > conditions for use of the tag. My proposal #4 is intended to make that > very clear, but resulted in inconveniently complex wording. > > I want to try a compromise: "tag for a non-signed language" > > I use "non-signed" instead or "non-sign" because "non-signed" is used > elsewhere while I never saw "non-sign" before. Non-signed is also a > self-sustained verb, while I do not really know what "non-sign" is > grammatically. > > That makes a new wording proposal for 5.4 be: > ------------------new > wording---------------------------------------------------------------- > > A sign language tag with a video media stream is interpreted as an > indication for sign language in the video stream. A tag for a non-signed > language with a text media stream is interpreted as an indication > for written language in the text stream. A tag for a non-signed language > with an audio media stream is interpreted as an indication for spoken > language in the audio stream. > > This document does not define any other use for language tags in > video media (such as how to indicate visible captions in the video > stream). > > In the IANA registry of language subtags perBCP 47 [RFC5646 ], a > language subtag with a Type field "extlang" combined with a Prefix > field value "sgn" indicates a tag for a sign language. The absence of such > "sgn" prefix indicates a tag for a non-signed language. > ------------------end of new wording--------------------------------------- >  Is this more acceptable by all? > > /Gunnar > > Den 2017-12-06 kl. 02:21, skrev Bernard Aboba: >> I can live with #1. >> >>> On Dec 5, 2017, at 5:29 PM, Gunnar Hellström wrote: >>> >>>> Den 2017-12-05 kl. 20:27, skrev Randall Gellens: >>>> The argument over the use of "non-" is pointless and a waste of time. We should not keep reopening it. The draft clear and unambiguous. >>> I tend to agree. >>> I provided four alternatives in order to try to reach consensus: >>> >>> 1. Leave "non-sign" as is. >>> >>> 2. Replace "non-sign language" with "non-sign-language". >>> >>> 3. Replace "non-sign" with "non-signed" >>> >>> 4. Replace "non-sign language tag" with "language tag for a language that is not signed" >>> >>> I can accept any of these, but have myself a slight preference for #3, "non-signed". >>> >>> Now, since Randall still prefers #1, I suggest that we close the issue with the conclusion that we keep it as it is in -19. >>> >>> Regards >>> >>> Gunnar >>> >>> >>> >>> >>> -- >>> ----------------------------------------- >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46 708 204 288 >>> >>> _______________________________________________ >>> SLIM mailing list >>> SLIM@ietf.org >>> https://www.ietf.org/mailman/listinfo/slim > > -- > ----------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------8DD2EB97D08B83651AA572EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I need to correct my statement that I have not seen the construct . "non-sign language" before. Now I have.

A very rough search gave hits where the use is quite similar to how it is used in draft version -19 in a term containing some more words as specifiers to a noun at the end.

Example 1:

https://www.cio.com/article/2381300/vertical-industries/microsoft-uses-kinect-to-interpret-sign-language-from-deaf-people.html

Search for "non-sign", and you will find:
"It's thought that the system could help deaf users make presentations to non-sign language speaking crowds. "

Example 2:

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2693477/

Search for "non-sign" and you will find:

"Several researchers (Corina et al., 1992; Emmorey et al., 2004; Marshall and Fink, 2001) have established that different neural systems subserve sign language production and non-sign language pantomimic expression."

I think that that confirms that the issue can be closed using any of the now 5 solutions I have presented.


Gunnar


Den 2017-12-06 kl. 18:21, skrev Gunnar Hellström:

Even if I have said that for me we can close the issue keeping the current wording, I want to explain my view of the wording and test a new proposal.

It is the term "non-sign language tag" we discuss.

That makes the "tag" to be the main noun, and what is before it can be seen as specifiers for "tag". I get the impression that Keith has seen this and want to make that clear.

However, the "non-sign" rather applies to the language. It is for when the language is not a signed language we want to express the conditions for use of the tag. My proposal #4 is intended to make that very clear, but resulted in inconveniently complex wording.

I want to try a compromise: "tag for a non-signed language"

I use "non-signed" instead or "non-sign" because "non-signed" is used elsewhere while I never saw "non-sign" before. Non-signed is also a self-sustained verb, while I do not really know what "non-sign" is grammatically.

That makes a new wording proposal for 5.4 be:
------------------new wording----------------------------------------------------------------

 A sign language tag with a video media stream is interpreted as an
   indication for sign language in the video stream.  A tag for a non-signed
   language with a text media stream is interpreted as an indication
   for written language in the text stream.  A tag for a non-signed language
   with an audio media stream is interpreted as an indication for spoken
   language in the audio stream.

   This document does not define any other use for language tags in
   video media (such as how to indicate visible captions in the video
   stream).

   In the IANA registry of language subtags per BCP 47 [RFC5646], a
   language subtag with a Type field "extlang" combined with a Prefix
   field value "sgn" indicates a tag for a sign language.  The absence of such
   "sgn" prefix indicates a tag for a non-signed language.
------------------end of new wording---------------------------------------
 Is this more acceptable by all?

/Gunnar

Den 2017-12-06 kl. 02:21, skrev Bernard Aboba:
I can live with #1.


On Dec 5, 2017, at 5:29 PM, Gunnar Hellström <gunnar.hellstrom@omnitor.se> wrote:


Den 2017-12-05 kl. 20:27, skrev Randall Gellens:
The argument over the use of "non-" is pointless and a waste of time. We should not keep reopening it.  The draft clear and unambiguous.

I tend to agree.
I provided four alternatives in order to try to reach consensus:

1. Leave "non-sign" as is.

2. Replace "non-sign language" with "non-sign-language".

3. Replace "non-sign" with "non-signed"

4. Replace "non-sign language tag" with "language tag for a language that is not signed"

I can accept any of these, but have myself a slight preference for #3, "non-signed".

Now, since Randall still prefers #1, I suggest that we close the issue with the conclusion that we keep it as it is in -19.

Regards

Gunnar




-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------8DD2EB97D08B83651AA572EB-- From nobody Thu Dec 7 11:08:28 2017 Return-Path: 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 76254126BF7 for ; Thu, 7 Dec 2017 11:08:27 -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 GWFGCvZSEDc2 for ; Thu, 7 Dec 2017 11:08:25 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 A741B12009C for ; Thu, 7 Dec 2017 11:08:25 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id i20so5982965uak.6 for ; Thu, 07 Dec 2017 11:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kIuUeLS9DNJ/EKv7QtROgKx9FstANXKdPdjjWwWPjpA=; b=q3GdMNRjV/F/9FB02jrdUOysEYH/a0JRxnsimxuu7vVCS1ogunaMsq+R65peYhcMAD rQ93iDPewTzHfG0yMncMIaNjhJAv5FSrqTLwqxp7xQ7DE1emi/BIAAhRKyhe+mQE2fb6 D6rWRoXThITLlugfnOUJya9zWlkilZWUqfJqEApOEFJKsMaRQMfBN40RcXriXMnJMT/o 7ZS565Kgqh3oepp1TJTDW4EHECys7u0n8viTTHibVaUgwDxylvp4C/kCKJ5lir3dp/A3 R86XxYHoaDEZX+saMifszzhK4yFdO4vlgl0BhIPlVeWGi1I3BUpgVSR5hYgcjgwUwSPl 0H9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kIuUeLS9DNJ/EKv7QtROgKx9FstANXKdPdjjWwWPjpA=; b=bZY7RZYpRTztqjA1qQU5AEZMDe35LsVp1fOnhC6wqp6W8BXUG4Ofj6I8VpY6ku/siE rDWkAAMGz+CBV2LffKn8ms5aJuWo+eJx47ay2afrnL26BPWopt4EvTjpNQbfRqtBjL5l PHX3yBG/sFn4uxK+nY7o5OrVVeHyNo0oHVd1TgztfWOvwi+UUiweRjwwq4LkR/PLDJP6 9ZRMwtsx8ncPTpee0HHzAtvN/fjzuJ2l1P9KJOFx2YfMX1OVUitgp3Md6XyukCjP1C5l OgD1oNhbRtMA+hbCzOqEREPxVHM/S+9O6RGNsKBh0uoxlBBm5rMZCKXo8FGk+p95Po+0 1KeQ== X-Gm-Message-State: AKGB3mL8SJJS3+k4DUkoozU5d8onexhIASdafOQg4ca8EbuF3me4X/PG NCRC5aNQYq82VK3uBj8M5sS91fJ+uhQFwW/RfJib6tWJ X-Google-Smtp-Source: AGs4zMZyWbMSznYczLdQByGG0KmDekHhIsj/rGjGuDrWYuyFiBvGbGV5o0vE1j8iZ6sDT9yo98InhujL8jJyFtuG4ak= X-Received: by 10.176.2.2 with SMTP id 2mr14804058uas.20.1512673704303; Thu, 07 Dec 2017 11:08:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.230 with HTTP; Thu, 7 Dec 2017 11:08:03 -0800 (PST) From: Bernard Aboba Date: Thu, 7 Dec 2017 14:08:03 -0500 Message-ID: To: slim@ietf.org Content-Type: multipart/alternative; boundary="001a113dc680ce6329055fc4ca04" Archived-At: Subject: [Slim] Use of "non-sign" term X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 19:08:27 -0000 --001a113dc680ce6329055fc4ca04 Content-Type: text/plain; charset="UTF-8" Gunnar has made a proposal for clarification of the language in Section 5.4 that would use "tag for a non-signed language" instead of "non-sign language": https://www.ietf.org/mail-archive/web/slim/current/msg01192.html IMHO, this would yield a (slight) improvement in clarity. At the same time, Gunnar has also found some use of the term "non-sign language": https://www.ietf.org/mail-archive/web/slim/current/msg01193.html Such as: "It's thought that the system could help deaf users make presentations to non-sign language speaking crowds. " and "Several researchers (Corina et al., 1992 ; Emmorey et al., 2004 ; Marshall and Fink, 2001 ) have established that different neural systems subserve sign language production and non-sign language pantomimic _expression_." It can be argued that the first usage uses non-sign to mean "crowds whose members do not speak any sign language", which is not the same meaning we are intending. However, the second usage appears much closer to our intention. Gunnar therefore proposes that the text can be left as is, and the only objection appears to be from Keith. Given the rather minor nature of the issue and the arguments, I believe WG census is that it is acceptable for the document to be advanced as is, with or without Gunnar's proposed change. --001a113dc680ce6329055fc4ca04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gunnar has made a=C2=A0 proposal for clarification of the = language in Section 5.4 that would use "tag for a non-signed language&= quot; instead of "non-sign language":

IMHO, this would yield a (slight) improvement in clarity.=C2=A0

At the same time, Gunnar has also found some use of the ter= m "non-sign language":
=C2=A0
Such = as:=C2=A0
"It's thought that the system could he= lp deaf users make presentations to non-sign language speaking crowds.=C2= =A0"

and=C2=A0

"Several researchers (Corina et al.= , 1992;=C2=A0Emmorey et al., 2004;=C2=A0Marshall and Fink, 2001) have est= ablished that different neural systems subserve sign language production an= d non-sign language pantomimic _expression_."
It can be argu= ed that the first usage uses non-sign to mean "crowds whose members do= not speak any sign language", which is not the same meaning we are in= tending.=C2=A0

However, the second us= age appears much closer to our intention.=C2=A0

Gunnar therefore proposes that the text can be left as is, and t= he only objection appears to be from Keith.=C2=A0
<= font color=3D"#000000" face=3D"Times New Roman, stixgeneral, serif">
Given the rather minor nature of the issue and the arguments, = I believe WG census is that it is acceptable for the document to be advance= d as is, with or without Gunnar's proposed change.
<= /div> --001a113dc680ce6329055fc4ca04-- From nobody Thu Dec 7 11:08:58 2017 Return-Path: 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 833F4126BF7; Thu, 7 Dec 2017 11:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 ai3UPaqkBTIV; Thu, 7 Dec 2017 11:08:54 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 938BA127076; Thu, 7 Dec 2017 11:08:54 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id p33so5992968uag.9; Thu, 07 Dec 2017 11:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=OL7RXS1dkrmLTBMT0n9z4mrq/YWYxEUVdBo3RaZYhaA=; b=J5+aKdOiNQGyKb1qq59kOEWchw3vua3PbrzJj8rUlZQUjqycdBrz7iwotVhI8QwMgQ UlhUchpxv4JVPjo8vmfaWd6GS8jFEBAkdBzAqDyUs+qP+/D9sOID/hA7Yc7a26OhCBIO Tzym0D1Fs4qF4aoZo3i72BK1PKQko2yIXkzciCIbseevsyjtJIL4YelB+AtzVhKMMAm9 1QYk7rT/gvdpucPcRYQyjZe4TY5eQHkw0BYhd7tevaNqLybQwDrFMjwkR/H8mEjcwUgr epqRxGuPyAIUr3P4EO7NOXYgSk3+3AEODPPQpVNI+DDpIvmooPz1SibKEec4fT6x1eaS /W5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=OL7RXS1dkrmLTBMT0n9z4mrq/YWYxEUVdBo3RaZYhaA=; b=QFJHsYJdX9zaXu+CP3UHQrJ9Q+pMGX+pNAoogFBxBYlETgvVrvjzG/xXzFFdwdtpfa ev1k99MSENRkaoDfaTnTbcB/JzLZZYKO1vzfNOdfcCYM9mMrBO/6mkKxO2qajJOmFuhD rAK2OxBsFLdpKkyg6krogB6JaSW8TcBbEojgsqXcKnncipLBjiwPKBxLoo3Xp+qH/vwC FoZ3HCiVMbQ8a70BW3LsS1itYBGWgX2TpdwDjNH20WYl93WZsXjUfA6tSVkCKmsn7vjn 4kC6iW6HmFRbA5yY6aYcPiFUoDaAS8s7ZYcTJweaQTurL4Cb3JPwoV9jhgjA1am7BbPO +YPQ== X-Gm-Message-State: AKGB3mIOQnCOp8/36uIMUW11M2AgTaeB2MbM7CfES4kl1HuYxYrgYkzf ZT2e5FsCNd/zdsnm3NN6+VHtDPZ7oW44tgkv0DCEuFN8 X-Google-Smtp-Source: AGs4zMbrhhhwQZTZqsxtZONAPZg7ykGoJoSG2qQA7Q+Lp/1M5A3/NR8nLwHIdt83Hmd8XrHI23jXGFf0wy7zfDlHk4Q= X-Received: by 10.159.40.169 with SMTP id d38mr10323919uad.137.1512673272593; Thu, 07 Dec 2017 11:01:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.230 with HTTP; Thu, 7 Dec 2017 11:00:52 -0800 (PST) From: Bernard Aboba Date: Thu, 7 Dec 2017 14:00:52 -0500 Message-ID: To: slim@ietf.org Cc: draft-ietf-slim-negotiating-human-language@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1228c4130871055fc4b177" Archived-At: Subject: [Slim] Final IPR check 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 19:08:56 -0000 --94eb2c1228c4130871055fc4b177 Content-Type: text/plain; charset="UTF-8" Dear Authors: The SLIM WG is working toward re-submission of draft-ietf-slim-negotiating-human-language to the IESG for publication as a Proposed Standard RFC. So far, no IPR statements have been submitted relating to draft-ietf-slim-negotiating-human-language. This email represents a final IPR check on this document. Are you aware of any IPR that applies to this draft? A reply is required from each author before a publication request can be considered. Thank you, Bernard Aboba (on behalf of the SLIM WG) --94eb2c1228c4130871055fc4b177 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors:=C2=A0
The SLIM WG is working toward re-submission of draft-i= etf-slim-negotiating-human-language to the IESG for publication as a P= roposed Standard RFC.=C2=A0

So f= ar, no IPR statements have been submitted relating to draft-ietf-slim-= negotiating-human-language.=C2=A0 This email represents a final IPR check o= n this document.=C2=A0

Are you a= ware of any IPR that applies to this draft?=C2=A0 A reply is required from = each author before a publication request can be considered.

Thank you,

Bernard Aboba
(on behalf of the SLIM WG)
--94eb2c1228c4130871055fc4b177-- From nobody Thu Dec 7 11:17:12 2017 Return-Path: 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 5314D124234 for ; Thu, 7 Dec 2017 11:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 w709UkraHRDg for ; Thu, 7 Dec 2017 11:17:08 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 DDB46127076 for ; Thu, 7 Dec 2017 11:17:07 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id i40so20336080qti.8 for ; Thu, 07 Dec 2017 11:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0Epoxx0C3Ad37CBIPbKkV283FMysrY7IEae1BR04BCk=; b=ZNVZSEaUhfrUokuwyl6fhh3MmwEgaLP3Ty6hTiuyt2NiZrhL2O/wTNjY9CoQ52nJ/3 L5oC2WZL37P3jXO1YqVZED99Zj4ToD60HdG+pgkv5Zp218+nBWsw94Sl4EgK29guVRWy woDqZfIzKkpz/hZrl8XNe+j2ocg+xp5mtXUp+hjsF6UOJTwVLBZEAi/5GDAenzJur+w1 ypiuEqiTJGUp5NjOKFlvwl50rQTXH79+oKa+oat17IjmFsqVbCew5UahLftwgqSscrk1 4NipwH8LxZJrZn8nwQnna8m0/0q7e8D2usCZvqq0GxCASCTneakQd4Ec1phAa6KbjbS8 Torg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0Epoxx0C3Ad37CBIPbKkV283FMysrY7IEae1BR04BCk=; b=D+WflLqDHQNAAu5Th+d2s+LbObkAXZ7EdkAdiEbb/WZkCrBUunFuaUCgaByg+fHaop VX2Ht6UCW0dwWkrimjHGT+gTn8ji3JMK7QPLD2rVmTuKPg3rxHRPoFNxHgi74BHs3Dl3 BNDggbyI8jemDwZMxtWixaXlBShRb8Mx2wSXbFoL9WaFyEUvpUU9p0wLT1gY/xb2wNHH AhwrGbYlMeoRWzTv/w8MPHeGkovH7CwKsy4sk6/eOKcZVQyvZTRVuZOg6Qr3Rl2dxnPp vok0+i2XINE5HvEJT8XFuAJX1Y+KW/lvs60T35iDjnZRzn8unN8wjUIC/zZEyD4FiL2j 38Vg== X-Gm-Message-State: AKGB3mKHg6x+aBDwhG8gfuhjIaawK90DG6Xica4LGlVY33FB4OCN8FyS J6D07QQFyR5zrStvICjX0Kgo8w== X-Google-Smtp-Source: AGs4zMa/adpqMX+aXJ+Fsr/ebdpzSA8XvHY4wXBTV/Od/dZylBINqckO7N6EwW3WkYKUhYSlRFUBiw== X-Received: by 10.55.124.67 with SMTP id x64mr32203755qkc.113.1512674226500; Thu, 07 Dec 2017 11:17:06 -0800 (PST) Received: from [10.33.193.2] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id w126sm2335975qkb.71.2017.12.07.11.17.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 11:17:05 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ACC2D681-97E8-4FC5-A668-69E269B8B927" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 7 Dec 2017 14:17:02 -0500 In-Reply-To: Cc: slim@ietf.org, draft-ietf-slim-negotiating-human-language@ietf.org To: Bernard Aboba References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Slim] Final IPR check 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 19:17:11 -0000 --Apple-Mail=_ACC2D681-97E8-4FC5-A668-69E269B8B927 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am not aware of any IPR on the document > On Dec 7, 2017, at 2:00 PM, Bernard Aboba = wrote: >=20 > Dear Authors:=20 >=20 > The SLIM WG is working toward re-submission of = draft-ietf-slim-negotiating-human-language to the IESG for publication = as a Proposed Standard RFC.=20 >=20 > So far, no IPR statements have been submitted relating to = draft-ietf-slim-negotiating-human-language. This email represents a = final IPR check on this document.=20 >=20 > Are you aware of any IPR that applies to this draft? A reply is = required from each author before a publication request can be = considered. >=20 > Thank you, >=20 > Bernard Aboba > (on behalf of the SLIM WG) > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim --Apple-Mail=_ACC2D681-97E8-4FC5-A668-69E269B8B927 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am not aware of any IPR on the document
On = Dec 7, 2017, at 2:00 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Dear Authors: 

The SLIM WG is working toward = re-submission of draft-ietf-slim-negotiating-human-language to the IESG for publication as a = Proposed Standard RFC. 

So far, no IPR statements have been submitted relating to = draft-ietf-slim-negotiating-human-language.  This = email represents a final IPR check on this document. 

Are you aware of any IPR that = applies to this draft?  A reply is required from each author before = a publication request can be considered.

Thank you,

Bernard Aboba
(on behalf of the SLIM WG)
_______________________________________________
SLIM = mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim

= --Apple-Mail=_ACC2D681-97E8-4FC5-A668-69E269B8B927-- From nobody Thu Dec 7 12:00:19 2017 Return-Path: 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 6C0201294FA; Thu, 7 Dec 2017 12:00:17 -0800 (PST) X-Quarantine-ID: 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.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yQ4FX2vOv_2K; Thu, 7 Dec 2017 12:00:15 -0800 (PST) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DD5AE129548; Thu, 7 Dec 2017 12:00:14 -0800 (PST) Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 7 Dec 2017 12:00:29 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Thu, 7 Dec 2017 12:00:12 -0800 To: Bernard Aboba , slim@ietf.org From: Randall Gellens Cc: draft-ietf-slim-negotiating-human-language@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Archived-At: Subject: Re: [Slim] Final IPR check 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 20:00:17 -0000 I am not aware of any applicable IPR. --Randall At 2:00 PM -0500 12/7/17, Bernard Aboba wrote: > Dear Authors: > > The SLIM WG is working toward re-submission of > draft-ietf-slim-negotiating-human-language to the IESG for > publication as a Proposed Standard RFC. > > So far, no IPR statements have been submitted relating to > draft-ietf-slim-negotiating-human-language. This email represents > a final IPR check on this document. > > Are you aware of any IPR that applies to this draft? A reply is > required from each author before a publication request can be > considered. > > Thank you, > > Bernard Aboba > (on behalf of the SLIM WG) > > _______________________________________________ > 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: --------------- esprit de l'escalier (es-preed-les-ka-lya; French; term): wit of the staircase ; repartee thought of only too late, on the way home From nobody Thu Dec 7 12:27:22 2017 Return-Path: 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 DB1FA127977 for ; Thu, 7 Dec 2017 12:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 bOfzPlVF6t9s for ; Thu, 7 Dec 2017 12:27:19 -0800 (PST) Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46AE31294E9 for ; Thu, 7 Dec 2017 12:27:19 -0800 (PST) X-Halon-ID: fd636d0c-db8c-11e7-8120-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.159.245]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id fd636d0c-db8c-11e7-8120-0050569116f7; Thu, 07 Dec 2017 21:27:06 +0100 (CET) To: Bernard Aboba , slim@ietf.org Cc: draft-ietf-slim-negotiating-human-language@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <93230360-40aa-752d-4052-ea4346a289b1@omnitor.se> Date: Thu, 7 Dec 2017 21:27:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C1F5090DC8D8EC405C6ED1AD" Content-Language: en-US Archived-At: Subject: Re: [Slim] Final IPR check 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 20:27:22 -0000 This is a multi-part message in MIME format. --------------C1F5090DC8D8EC405C6ED1AD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I am not aware of any IPR applicable to the draft. Gunnar Hellström ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 Den 2017-12-07 kl. 20:00, skrev Bernard Aboba: > Dear Authors: > > The SLIM WG is working toward re-submission of > draft-ietf-slim-negotiating-human-language to the IESG for publication > as a Proposed Standard RFC. > > So far, no IPR statements have been submitted relating to > draft-ietf-slim-negotiating-human-language. This email represents a > final IPR check on this document. > > Are you aware of any IPR that applies to this draft?  A reply is > required from each author before a publication request can be considered. > > Thank you, > > Bernard Aboba > (on behalf of the SLIM WG) > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- --------------C1F5090DC8D8EC405C6ED1AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I am not aware of any IPR applicable to the draft.

Gunnar Hellström

-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

Den 2017-12-07 kl. 20:00, skrev Bernard Aboba:
Dear Authors: 

The SLIM WG is working toward re-submission of draft-ietf-slim-negotiating-human-language to the IESG for publication as a Proposed Standard RFC. 

So far, no IPR statements have been submitted relating to draft-ietf-slim-negotiating-human-language.  This email represents a final IPR check on this document. 

Are you aware of any IPR that applies to this draft?  A reply is required from each author before a publication request can be considered.

Thank you,

Bernard Aboba
(on behalf of the SLIM WG)


_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


--
--------------C1F5090DC8D8EC405C6ED1AD-- From nobody Thu Dec 7 13:44:05 2017 Return-Path: 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 868F0127286 for ; Thu, 7 Dec 2017 13:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-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 gl-rE3jlqpKM for ; Thu, 7 Dec 2017 13:44:01 -0800 (PST) Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02091126DFE for ; Thu, 7 Dec 2017 13:44:00 -0800 (PST) X-Halon-ID: ab4bd2f5-db97-11e7-aafc-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [83.209.159.245]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id ab4bd2f5-db97-11e7-aafc-005056917a89; Thu, 07 Dec 2017 22:43:32 +0100 (CET) To: Bernard Aboba , slim@ietf.org References: From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Thu, 7 Dec 2017 22:43:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7AB4FAB846A215E0D84556FE" Content-Language: en-US Archived-At: Subject: Re: [Slim] Use of "non-sign" term X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 21:44:03 -0000 This is a multi-part message in MIME format. --------------7AB4FAB846A215E0D84556FE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Bernard, I agree with your conclusion and suggest that you make the final decision on which variant to proceed with. Thanks, Gunnar Den 2017-12-07 kl. 20:08, skrev Bernard Aboba: > Gunnar has made a  proposal for clarification of the language in > Section 5.4 that would use "tag for a non-signed language" instead of > "non-sign language": > https://www.ietf.org/mail-archive/web/slim/current/msg01192.html > > IMHO, this would yield a (slight) improvement in clarity. > > At the same time, Gunnar has also found some use of the term "non-sign > language": > https://www.ietf.org/mail-archive/web/slim/current/msg01193.html > Such as: > "It's thought that the system could help deaf users make presentations > to non-sign language speaking crowds. " > > and > > "Several researchers (Corina et al., 1992 > ; Emmorey et > al., 2004 ; > Marshall and Fink, 2001 > ) have > established that different neural systems subserve sign language > production and non-sign language pantomimic _expression_." > > It can be argued that the first usage uses non-sign to mean "crowds > whose members do not speak any sign language", which is not the same > meaning we are intending. > > However, the second usage appears much closer to our intention. > > Gunnar therefore proposes that the text can be left as is, and the > only objection appears to be from Keith. > > Given the rather minor nature of the issue and the arguments, I > believe WG census is that it is acceptable for the document to be > advanced as is, with or without Gunnar's proposed change. > > > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------7AB4FAB846A215E0D84556FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Bernard,

I agree with your conclusion and suggest that you make the final decision on which variant to proceed with.

Thanks,

Gunnar


Den 2017-12-07 kl. 20:08, skrev Bernard Aboba:
Gunnar has made a  proposal for clarification of the language in Section 5.4 that would use "tag for a non-signed language" instead of "non-sign language":

IMHO, this would yield a (slight) improvement in clarity. 

At the same time, Gunnar has also found some use of the term "non-sign language":
 
Such as: 
"It's thought that the system could help deaf users make presentations to non-sign language speaking crowds. "

and 

"Several researchers (Corina et al., 1992; Emmorey et al., 2004; Marshall and Fink, 2001) have established that different neural systems subserve sign language production and non-sign language pantomimic _expression_."

It can be argued that the first usage uses non-sign to mean "crowds whose members do not speak any sign language", which is not the same meaning we are intending. 

However, the second usage appears much closer to our intention. 

Gunnar therefore proposes that the text can be left as is, and the only objection appears to be from Keith. 

Given the rather minor nature of the issue and the arguments, I believe WG census is that it is acceptable for the document to be advanced as is, with or without Gunnar's proposed change.


_______________________________________________
SLIM mailing list
SLIM@ietf.org
https://www.ietf.org/mailman/listinfo/slim


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------7AB4FAB846A215E0D84556FE-- From nobody Thu Dec 7 13:57:02 2017 Return-Path: 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 ACAF3127599 for ; Thu, 7 Dec 2017 13:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=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 TpkjXdk3P8nB for ; Thu, 7 Dec 2017 13:56:58 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 55E72126DCA for ; Thu, 7 Dec 2017 13:56:58 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id o23so7683501otd.1 for ; Thu, 07 Dec 2017 13:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A03J0gtU3zbV3WLbVhxgBKmJAL/50NFtrE9znFN91+w=; b=bvmQKADGv5iEmsz9G1XtrTX2k3xShOjGXy8j0SOBDED0xjjjUbb0lokrePETROFKJq uX3fWeUOd7S0R5JMkU2oXbc/f+Rj5hT2r7jYzzknD2QrKSCVoX3lesTDgq/mv2JG2CPL Bx6ZJIuXt7CYCYfbnKu7Ii/MDvUnE/w4AiVevs5l6PELvJjztBWjOo4M9M/jULRHNIBg 7icYZ4oYrUjE6UNbjJ1ujtwwyOFHdCaegbti1OOcXolmqES+ABDYVQGfRt0I07cBVhyK Gr1vRtJtEDFYT0ZRDBR5vEeCEdvxQCvkMGbhLqx3rSsyNQyLzX1EUn3EZFW/q+e84LVa vFnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A03J0gtU3zbV3WLbVhxgBKmJAL/50NFtrE9znFN91+w=; b=HZMgm1Z5DnhjjbsejUdB4NCs2+eVQDxuT6VXPL/zKqmwS+bUvve1vmkj2ZuZY5Y2aW FGoceHmWUA3YhJP2WEADyj/Sf+OUL1vo4Wh3tk+Ia/7C5k0z2nf7I8QgaU+4r6BmHxyE TQ91NMidkDSQjZaVzMrFkYho/OVTwjqy7z7FX2x5qxw4cYOeb44LzLVB8a2Z1h3xnBSM PLthXtfsijeJtYg24TQZRrffSly4se4nFKblikGodKZq9mt3sgDBQb2ep6UIrQtUk7ep opCp3wO1kP1p2YvQwBz4Sz5ArHksy8ornmgGsBj1syWqt2GyRDFZb+JVzE4ZWERRJTxF 7MQw== X-Gm-Message-State: AKGB3mJI7waQf/b/lmN4yVorvU6RRayENip4pCtKuGh2CUOI9dYslN5K EQY0LwoZVnRmtm9G539Rdl4WtUaA X-Google-Smtp-Source: AGs4zMaav0sGwjSHeeJ+u1Pw0zJkYDoU5DyCved5iLOZg/6RFmXI5YHs7o1i1oxBTO7iSeM+0anLXw== X-Received: by 10.157.9.177 with SMTP id q46mr9779088otd.285.1512683817089; Thu, 07 Dec 2017 13:56:57 -0800 (PST) Received: from [10.236.163.45] ([73.85.204.221]) by smtp.gmail.com with ESMTPSA id y2sm2718799otg.51.2017.12.07.13.56.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 13:56:56 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-C8C228B8-2DD9-4507-80ED-7172CCF528E6 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15C114) In-Reply-To: Date: Thu, 7 Dec 2017 16:56:55 -0500 Cc: slim@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <818F1627-EB0F-4310-802C-2CB2E4D7A74B@gmail.com> References: To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= Archived-At: Subject: Re: [Slim] Use of "non-sign" term X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 21:57:01 -0000 --Apple-Mail-C8C228B8-2DD9-4507-80ED-7172CCF528E6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am working on a publication request to the IESG. If there are further issu= es, they can be raised in IETF last call. > On Dec 7, 2017, at 4:43 PM, Gunnar Hellstr=C3=B6m wrote: >=20 > Bernard, > I agree with your conclusion and suggest that you make the final decision o= n which variant to proceed with. >=20 > Thanks, >=20 > Gunnar >=20 >> Den 2017-12-07 kl. 20:08, skrev Bernard Aboba: >> Gunnar has made a proposal for clarification of the language in S= ection 5.4 that would use "tag for a non-signed language" instead of "non-si= gn language": >> https://www.ietf.org/mail-archive/web/slim/current/msg01192.html >>=20 >> IMHO, this would yield a (slight) improvement in clarity.=20 >>=20 >> At the same time, Gunnar has also found some use of the term "non-sign la= nguage": >> https://www.ietf.org/mail-archive/web/slim/current/msg01193.html >> =20 >> Such as:=20 >> "It's thought that the system could help deaf users make presentations to= non-sign language speaking crowds. " >>=20 >> and=20 >>=20 >> "Several researchers (Corina et al., 1992; Emmorey et al., 2004; Marshall= and Fink, 2001) have established that different neural systems subserve sig= n language production and non-sign language pantomimic _expression_." >>=20 >> It can be argued that the first usage uses non-sign to mean "crowds whose= members do not speak any sign language", which is not the same meaning we a= re intending.=20 >>=20 >> However, the second usage appears much closer to our intention.=20 >>=20 >> Gunnar therefore proposes that the text can be left as is, and the only o= bjection appears to be from Keith.=20 >>=20 >> Given the rather minor nature of the issue and the arguments, I believe W= G census is that it is acceptable for the document to be advanced as is, wit= h or without Gunnar's proposed change. >>=20 >>=20 >> _______________________________________________ >> SLIM mailing list >> SLIM@ietf.org >> https://www.ietf.org/mailman/listinfo/slim >=20 > --=20 > ----------------------------------------- > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > +46 708 204 288 --Apple-Mail-C8C228B8-2DD9-4507-80ED-7172CCF528E6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I am working on a publicati= on request to the IESG. If there are further issues, they can be raised in I= ETF last call.

On Dec 7, 2017, at 4:43 PM, Gunnar Hellstr=C3=B6= m <gunnar.hellstrom@omnito= r.se> wrote:

=20 =20 =20

Bernard,

I agree with your conclusion and suggest that you make the final decision on which variant to proceed with.

Thanks,

Gunnar


Den 2017-12-07 kl. 20:08, skrev Bernard Aboba:
Gunnar has made a  proposal for clarification of= the language in Section 5.4 that would use "tag for a non-signed language" instead of "non-sign language":

IMHO, this would yield a (slight) improvement in clarity. =

At the same time, Gunnar has also found some use of the term "non-sign language":
 
Such as: 
"It's thought that the system could help deaf users make presentations to non-sign language speaking crowds. "

and 

"Several researchers (Corina et al., 1992; Emmorey et al., 2004; Marshall and Fink, 2001) have established that different neural systems subserve sign language production and non-sign language pantomimic _expression_."

It can be argued that the first usage uses non-sign to mean "crowds whose members do not speak any sign language", which is not the same meaning we are intending. 

However, the second usage appears much closer to our intention. 

Gunnar therefore proposes that the text can be left as is, and the only objection appears to be from Keith. 

Given the rather minor nature of the issue and the arguments, I believe WG census is that it is acceptable for the document to be advanced as is, with or without Gunnar's proposed change.


_______________________________________________
SLIM mailing list
SLIM@iet=
f.org
https://www.ietf.org/mailman/listinfo/slim


--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
=20
= --Apple-Mail-C8C228B8-2DD9-4507-80ED-7172CCF528E6-- From nobody Thu Dec 7 17:33:03 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13032126C26; Thu, 7 Dec 2017 17:33:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bernard Aboba To: X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Cc: slim@ietf.org, iesg-secretary@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com Message-ID: <151269678103.5938.8457176370367933911.idtracker@ietfa.amsl.com> Date: Thu, 07 Dec 2017 17:33:01 -0800 Archived-At: Subject: [Slim] Publication has been requested for draft-ietf-slim-negotiating-human-language-19 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 01:33:01 -0000 Bernard Aboba has requested publication of draft-ietf-slim-negotiating-human-language-19 as Proposed Standard on behalf of the SLIM working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ From nobody Fri Dec 8 11:06:15 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC3412773A; Fri, 8 Dec 2017 11:06:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk CC: slim@ietf.org, alexey.melnikov@isode.com, draft-ietf-slim-negotiating-human-language@ietf.org, slim-chairs@ietf.org, bernard.aboba@gmail.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151275997382.5896.5317823005801633927.idtracker@ietfa.amsl.com> Date: Fri, 08 Dec 2017 11:06:13 -0800 Archived-At: Subject: [Slim] Last Call: (Negotiating Human Language in Real-Time Communications) to Proposed Standard X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 19:06:14 -0000 The IESG has received a request from the Selection of Language for Internet Media WG (slim) to consider the following document: - 'Negotiating Human Language in Real-Time Communications' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-12-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. This document adds new SDP media-level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important with emergency calls, where a call can be handled by a call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non-emergency calls as well (as an example, when calling a company call center). This document describes the need and a solution using new SDP media attributes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-saintandre-sip-xmpp-chat: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat (None - ) From nobody Sat Dec 23 06:06:59 2017 Return-Path: X-Original-To: slim@ietf.org Delivered-To: slim@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6C312D77B; Sat, 23 Dec 2017 06:06:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley To: Cc: slim@ietf.org, ietf@ietf.org, draft-ietf-slim-negotiating-human-language.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151403800610.30014.8081337459008102936@ietfa.amsl.com> Date: Sat, 23 Dec 2017 06:06:46 -0800 Archived-At: Subject: [Slim] Genart last call review of draft-ietf-slim-negotiating-human-language-19 X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.22 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 14:06:46 -0000 Reviewer: Dale Worley Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-slim-negotiating-human-language-19 Reviewer: Dale R. Worley Review Date: 2017-12-23 IETF LC End Date: 2017-12-22 IESG Telechat date: [unknown] Summary: This draft is ready for publication as a Standards Track RFC. No issues. [END]