Re: [Ltru] Proposed -t0- subtag

"Broome, Karen" <> Mon, 25 July 2011 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 166D721F8B6F for <>; Mon, 25 Jul 2011 11:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.267
X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dzzmi7dWqRQV for <>; Mon, 25 Jul 2011 11:09:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 76B9A21F8419 for <>; Mon, 25 Jul 2011 11:09:38 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Mon, 25 Jul 2011 18:09:31 +0000
Received: from mail127-va3 (localhost.localdomain []) by (Postfix) with ESMTP id BEC7A401B3; Mon, 25 Jul 2011 18:09:30 +0000 (UTC)
X-SpamScore: -33
X-BigFish: VPS-33(zzc89bh9371M542M98dKzz1202hzz1033IL8275bh8275dhz2fh668h839h93fh61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPVD:NLI;;; EFVD:NLI
Received-SPF: pass (mail127-va3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail127-va3 (localhost.localdomain []) by mail127-va3 (MessageSwitch) id 1311617370379250_28228; Mon, 25 Jul 2011 18:09:30 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 595BD1258046; Mon, 25 Jul 2011 18:09:30 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server id; Mon, 25 Jul 2011 18:09:25 +0000
Received: from ( []) by (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id p6PI9B00026164; Mon, 25 Jul 2011 18:09:25 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.2) with ESMTP id p6PI9BRi016335 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 25 Jul 2011 18:09:25 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 25 Jul 2011 14:09:09 -0400
Received: from ([]) by ([]) with mapi; Mon, 25 Jul 2011 11:09:08 -0700
From: "Broome, Karen" <>
To: Doug Ewell <>, "" <>
Date: Mon, 25 Jul 2011 11:09:04 -0700
Thread-Topic: [Ltru] Proposed -t0- subtag
Thread-Index: AcxK8r2GZkle3tTORdGZ0oyjtGfCCQAAXnlA
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [Ltru] Proposed -t0- subtag
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Jul 2011 18:09:52 -0000

Well, I had considered registering a singleton on behalf of the Society of Motion Pictures and Television Engineers -- the xml:lang compliant tags are now specified in many, if not most, new industry standards. (Things are certainly still in transition from older ISO 639 classifications.) But SMPTE might benefit from more motion picture specific values (possible values: original, dubbed, captioned, subtitled, audio description). 

But I also wonder about the general utility of this and hadn't really broached the subject of "tone" or had an immediate need for something like that. It's interesting, but I think maybe it goes beyond language identification into aspects of the delivery and content. Fun stuff to work on, but not sure I need it now. But I think "spoken" and "written" are two distinctions that definitely help identify the "language". I realize this is a somewhat controversial belief.


Karen Broome

-----Original Message-----
From: Doug Ewell [] 
Sent: Monday, July 25, 2011 10:43 AM
Cc: Broome, Karen
Subject: Re: [Ltru] Proposed -t0- subtag

"Broome, Karen" <Karen dot Broome at am dot sony dot com> wrote:

> Sorry, I was thinking the original ISO registration had gone through
> as 'No Linguistic content' but now I'm remembering that this was
> somewhat of a partner tag for 'zxx' which does mean that. I wasn't
> referencing the RFC text per se, which gives the user an option — and
> I'm OK with the option. Still, I generally find this muddy. I don't
> want to look to a script tag to define the language mode because there
> are commonly used language modes that are not written forms. The
> disconnect with the 'zxx' tag this tags mirrors may be another reason
> to avoid use to indicate the language mode.

I think what you are finding "muddy" is not the subtag 'Zxxx', which
does have a fairly clear meaning in BCP 47, but rather the use of a
script (writing system) subtag to tag content that isn't written.  I can
see how this is unintuitive.  I think the answer is that BCP 47 tags
aren't really designed to tag modes out of the box, and that, in turn,
is exactly what extensions are for.

If you or anyone else did want to create an extension RFC for modes
('m', perhaps), you'd probably want to start the discussion by
identifying the initial values (spoken, written, signed, anything else?)
and setting constraints.  As examples of the latter, you'd want to
establish whether male vs. female, shouting vs. whispering, friendly vs.
angry, handwritten vs. printed, etc. are in scope.

Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14 | | @DougEwell ­