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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Tue, 21 November 2017 21:07 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 379F4129BDA for <slim@ietfa.amsl.com>; Tue, 21 Nov 2017 13:07:52 -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 tG_pr1owInde for <slim@ietfa.amsl.com>; Tue, 21 Nov 2017 13:07:47 -0800 (PST)
Received: from bin-vsp-out-02.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 CAF961270AC for <slim@ietf.org>; Tue, 21 Nov 2017 13:07:46 -0800 (PST)
X-Halon-ID: fb749840-ceff-11e7-96ae-005056917f90
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [77.53.37.96]) by bin-vsp-out-02.atm.binero.net (Halon) with ESMTPSA id fb749840-ceff-11e7-96ae-005056917f90; Tue, 21 Nov 2017 22:07:29 +0100 (CET)
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: slim@ietf.org
References: <CAOW+2dsZtuciPiKMfif=ZmUqBcUd9TyYtL5gPYDp7ZfLOHHDBA@mail.gmail.com> <p06240600d637c6f98ecc@99.111.97.136> <CAOW+2dv5NSiCbW=p1exvPV=PF8YCVdiz2gi-OCxmaUB-jGe22w@mail.gmail.com> <p06240600d6389cd2043f@99.111.97.136> <97d9a6b8-de3b-9f79-483b-18376fcf0ced@omnitor.se> <CAOW+2dtpRoeYkMJzX9vyNUojJDax4DQUU2F4PauBwt1sm-83Hg@mail.gmail.com> <55f2b336-3f14-f49a-ec78-f00b0373db00@omnitor.se> <bc5b7aa5-7c6a-5096-47d0-01e5ee079e93@omnitor.se> <CAOW+2duUPsTY=Ygzwfu0eOYbHaBAwMqm+oxA6AdMXinxTMNM1A@mail.gmail.com> <165d2c07-19ca-f2b1-2aac-3aac842b97e9@omnitor.se> <CAOW+2dsrRoCE4YQ1U+y448C4qmMY1Hb+8jM=aTyzvsPBYA0akg@mail.gmail.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <21a8709d-87f1-e1e4-10cf-340e6b7e43ce@omnitor.se>
Date: Tue, 21 Nov 2017 22:07:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAOW+2dsrRoCE4YQ1U+y448C4qmMY1Hb+8jM=aTyzvsPBYA0akg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------65B0D4D6C0C82606FC8C0720"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/zVbtuNXmupgQepebwWC3JAZOYv0>
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2017 21:07:52 -0000

Den 2017-11-21 kl. 16:59, skrev Bernard Aboba:
> [BA] LGTM.  Do you recall what the objection was to the term 
> "spoken/written language"?
<GH> It was in this mail in the archive:
https://www.ietf.org/mail-archive/web/slim/current/msg00744.html

It is Addison commenting on proposals for section 5.4, and specifically 
commenting on this proposed point:

>>>  2.    Text captions included in the video stream SHALL be indicated
>>> by a Language-Tag for spoken/written language.

<GH>And the comment from Addison was:

"I'm not sure what #2 really means. Shouldn't text captions be indicated by the written language
rather than the spoken language? And I'm not sure what "spoken/written language" means. "

<GH>My answer next day on this point was:

"
#2 was: "

2.    Text captions included in the video stream SHALL be indicated
by a Language-Tag for spoken/written language."

Yes, the intention is to use written language in the video stream. 
Thereare technologies for that.Since the language subtags in the IANA 
registry are combined for spokenlanguages and written languages, I call 
them Language-Tags forspoken/written language.It would be misleading to 
say that we use a Language-Tag for a writtenlanguage, because the same 
tag could in another context mean a spokenlanguage.Since we have the 
script subtag Zxxx for non-written, we do not need toconstruct an 
explicit tag for the written language tag, it should besufficient with 
our specification of the use in our case.In my latest recent proposal, I 
still have a very similar wording. Sinceyou had problems understanding 
it, there might still be a need to tuneit. Can you propose wording?This is the current
  proposal:

"   2.    Text captions included in the video stream SHOULD be indicated
   by a humintlang attribute with Language-Tag for spoken/written language.
"
<GH>Addison responded in https://www.ietf.org/mail-archive/web/slim/current/msg00757.html

> Yes, the intention is to use written language in the video stream. There are
> technologies for that.

I'm aware of that. My concern is that in this case "spoken/written" is applied to "text captions", which are not spoken be definition? This section is talking about the differences between identifying spoken and written language. The text captions fall into the written side of the equation, no?

I'd probably prefer to see something like
"2. Text captions included in the video stream SHOULD include a Language-Tag to identify the language."

> Since the language subtags in the IANA registry are combined for spoken
> languages and written languages, I call them Language-Tags for spoken/written
> language.

The language subtags are for languages--all modalities. My comment here
is that "spoken/written" adds no information.

> It would be misleading to say that we use a Language-Tag for a written
> language, because the same tag could in another context mean a spoken
> language.

One uses a Language-Tag for indicating the language. When the text is written,
sometimes the user will pick a different language tag (zh-Hant-HK) than they
might choose for spoken text (yue-HK, zh-cmn-HK, etc.). Sometimes (actually,
nearly all the time except for special cases) the language tag for the spoken
and written language is the same tag (en-US, de-CH, ja-JP, etc.). Again, the
modality of the language is a separate consideration from the language.
Nearly always, it is better to use the same tag for both spoken and written
content rather than trying to use the tag to distinguish between them:
different Content-Types require different decoders anyway, but it is really
useful to say "give me all of the 'en-US' content you have" or "do you have
  content for a user who speaks 'es'"

<GH> The result was that we modified text in a few places where we had used
"spoken/written language tag".

Now, the term has reappeared, and I assume that the language experts still
have the same concerns as in February.

When we use the term, it is intended to mean "tag for non-signed language".
Therefore it is not appropriate to just replace it with "Language tag"
and we need to decide what to do. Shall we define what we mean with
"spoken/written language tag" or try to reword the sentences containing that term?
  


Gunnar

>
> Gunnar had said:
>
> "A proposal trying to act on issues 1-4 plus other minor rewording:
>  ---------------------------------------------------------------------------------------------------------------
> 5.4 Media, Language and Modality indications
> A spoken/written language tag included in a text media description is 
> an indication for written language. A spoken/written language tag 
> included in an audio media description is an indication for spoken 
> language. A sign language tag included in a video media description is 
> an indication for sign language in the video stream.
>
> A sign language can be identified by the existence in the IANA 
> registry of language subtags according to BCP 47 [RFC5646] of the 
> language subtag with the Type field "extlang" combined with the Prefix 
> field value "sgn". A spoken/written language tag can be identified by 
> not having any such "sgn" prefix.
>
> This document does not define the use of sign language tags in text or 
> audio media.  By including a language tag for spoken language in a 
> video description and using the "lip sync" grouping mechanism defined 
> in [RFC5888] it is possible to indicate synchronized audio and video 
> so as to support lip reading. Other use of spoken/written language 
> tags in a video description (such as for video embedded text captions) 
> is not defined in this document.
>
> Use of 'hlang' attributes may appear in other media descriptions, such 
> as "message" and "application" supported by further work or 
> application specific agreements."
>
> On Tue, Nov 21, 2017 at 12:00 AM, Gunnar Hellström 
> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>
>     Den 2017-11-20 kl. 23:16, skrev Bernard Aboba:
>>     Can we include text from Brian's suggestion? For example:
>>
>>     "If a sign language is signaled in a video stream, it is
>>     interpreted as an indication that sign language will appear in
>>     the video. A sign language can be identified by the existence in
>>     the IANA registry of language subtags according to BCP 47
>>     [RFC5646] of the language subtag with the Type field "extlang"
>>     combined with the Prefix field value "sgn". A spoken/written
>>     language tag can be identified by not having any such "sgn"
>>     prefix. This document does not define any other use for language
>>     tags in video media (such as how to indicate a desire for visible
>>     captions).
>>
>>     This document does not define the use of sign language tags in
>>     text or audio media. If a spoken/written language tag is included
>>     in text media, it indicates a desire for written language. If a
>>     spoken/written language tag is included in audio media, it is
>>     interpreted as an indication that spoken language is desired. 
>>     Using the "lip sync" grouping mechanism defined in [RFC5888], it
>>     is possible to indicate the desire to synchronize audio and video
>>     so as to support lip reading.
>>
>>     Use of language tags may appear in other media, such as "message"
>>     and "application".  Such use may be supported by further work or
>>     application specific agreement."
>     <GH>Quite good. I see four small issues.
>     1: "WILL appear" is not right in the first sentence. The
>     indication may be just one of a set of indicated languages.
>     2: The first paragraph says that we do not define other use of
>     language tags in video than for sign language, but the second
>     paragraph defines how to use tags for spoken language in video.
>     3: I prefer to start with the three normal clearly supported cases.
>     4: The indications sometimes indicate desire, sometimes
>     capability. Therefore the word "desire" is not suitable in the
>     explanations.
>     5: In the LC review, we had some resistance against using the term
>     "spoken/written language tag". It appears again in the proposal. I
>     do not understand the resistance and I do not know how strict it
>     was, but we need to know if it is ok to use that term.  (I do not
>     change that for now in the proposal below.)
>
>
>     A proposal trying to act on issues 1-4 plus other minor rewording:
>      ---------------------------------------------------------------------------------------------------------------
>     5.4 Media, Language and Modality indications
>     A spoken/written language tag included in a text media description
>     is an indication for written language. A spoken/written language
>     tag included in an audio media description is an indication for
>     spoken language. A sign language tag included in a video media
>     description is an indication for sign language in the video stream.
>
>     A sign language can be identified by the existence in the IANA
>     registry of language subtags according to BCP 47 [RFC5646] of the
>     language subtag with the Type field "extlang" combined with the
>     Prefix field value "sgn". A spoken/written language tag can be
>     identified by not having any such "sgn" prefix.
>
>     This document does not define the use of sign language tags in
>     text or audio media.  By including a language tag for spoken
>     language in a video description and using the "lip sync" grouping
>     mechanism defined in [RFC5888] it is possible to indicate
>     synchronized audio and video so as to support lip reading. Other
>     use of spoken/written language tags in a video description (such
>     as for video embedded text captions) is not defined in this document.
>
>     Use of 'hlang' attributes may appear in other media descriptions,
>     such as "message" and "application" supported by further work or
>     application specific agreements.
>
>     ------------------------------------------------------------------
>
>
>>
>>
>>
>>     On Mon, Nov 20, 2017 at 1:14 PM, Gunnar Hellström
>>     <gunnar.hellstrom@omnitor.se
>>     <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>>
>>         A new proposal for new text taking in latest discussion of
>>         Bernard, Paul and Brian:
>>
>>         -----Old text----
>>
>>
>>               5.4 Undefined Combinations
>>
>>         The behavior when specifying a non-signed language tag for a
>>         video media stream, or a signed language tag for an audio or
>>         text media stream, is not defined in this document. The
>>         problem of knowing which language tags are signed and which
>>         are not is out of scope of this document.
>>
>>         -----New text------------
>>         5.4 Media, Language and Modality indications
>>
>>         The combination of Language tags and other information in the
>>         media descriptions shall be composed so that the intended
>>         modality can be concluded by the negotiating parties. The
>>         following combinations of language tags and media provide
>>         obvious information about the modality: sign language tags in
>>         video media indicate signed modality, language tags in audio
>>         media indicate spoken modality and language tags in text
>>         media indicate written modality. The examples in this
>>         specification are all from this set of three obvious
>>         language/media/modality combinations.
>>
>>         A sign language can be identified by the existence in the
>>         IANA registry of language subtags according to BCP 47
>>         [RFC5646] of the language subtag with the Type field
>>         "extlang" combined with the Prefix field value "sgn".
>>         A specific spoken or written language can be identified by
>>         not having any such "sgn" Prefix.
>>
>>         Use of language may appear in other media, such as "message"
>>         and "application". Video media may be used for other
>>         modalities than signed, e.g. a view of a speaker or text
>>         captions. Such use may be supported by further work or
>>         application specific agreements for evaluation of the
>>         intended modality.
>>
>>         ---------------------------End of new
>>         text---------------------------------------
>>
>>
>>         Den 2017-11-20 kl. 21:44, skrev Gunnar Hellström:
>>>         Den 2017-11-20 kl. 19:41, skrev Bernard Aboba:
>>>>         Gunnar said:
>>>>
>>>>         "5.4 Media, Language and Modality indications
>>>>
>>>>         The combination of Language tags and other information in
>>>>         the media descriptions should be composed so that the
>>>>         intended modality can be concluded by the negotiating
>>>>         parties. "
>>>>
>>>>         [BA] Is the "should" intended to be normative?
>>>         <GH>You are right that SHOULD should be avoided and it would
>>>         be better to say MUST if we can. But I can imagine limited
>>>         area applications having application agreements e.g. saying
>>>         that a non-signed language tag in video media means a view
>>>         of a talking person.   The negotiating applications know
>>>         about this agreement so they can make the conclusion. So, if
>>>         such situations can be included in how the parties make
>>>         their conclusions, we can change to MUST.
>>>>
>>>>         The following combinations of language tags and media
>>>>         provide obvious information about the modality: sign
>>>>         language tags in video media indicate signed modality... A
>>>>         sign language can be identified by the existence in the
>>>>         IANA registry of language subtags according to BCP 47
>>>>         [RFC5646] of the language subtag with the Type field
>>>>         "extlang" combined with the Prefix field value "sgn". A
>>>>         specific spoken or written language can be identified by
>>>>         not having any such "sgn" Prefix.
>>>>
>>>>         Use of language may appear in other media, such as
>>>>         "message" and "application". Video media may be used for
>>>>         other modalities than signed. Such use may be supported by
>>>>         further work or application specific agreements or
>>>>         indications for evaluation of the intended modality."
>>>>
>>>>         [BA] Assume we can confirm the mechanism for distinguishing
>>>>         signed/non-signed languages, this part seems relatively solid.
>>>>
>>>>         spoken language tags for audio media indicate spoken
>>>>         modality and written language tags for text media indicate
>>>>         written modality. The examples in this specification are
>>>>         all from this set of three obvious language/media/modality
>>>>         combinations.
>>>>
>>>>         [BA]  This is where the ground gets less solid - we don't
>>>>         really have a general mechanism for distinguishing spoken
>>>>         and written modality among non-signed languages. Perhaps we
>>>>         should just say "language tags in audio media indicate
>>>>         spoken modality and language tags in text media indicate
>>>>         written modality".
>>>         Yes, right, that is better wording.
>>>
>>>         Gunnar
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         On Mon, Nov 20, 2017 at 9:25 AM, Gunnar Hellström
>>>>         <gunnar.hellstrom@omnitor.se
>>>>         <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>>>>
>>>>             It is not the signed languages that are causing the
>>>>             problem. It is the spoken and written, when used in
>>>>             other media than the obvious audio and text media.
>>>>
>>>>             And we should specify what is obvious and well defined
>>>>             and not, so here is a new shorter proposal for section 5.4.
>>>>
>>>>             -----Old text----
>>>>
>>>>
>>>>                   5.4 Undefined Combinations
>>>>
>>>>             The behavior when specifying a non-signed language tag
>>>>             for a video media stream, or a signed language tag for
>>>>             an audio or text media stream, is not defined in this
>>>>             document. The problem of knowing which language tags
>>>>             are signed and which are not is out of scope of this
>>>>             document.
>>>>
>>>>             -----New text------------
>>>>             5.4 Media, Language and Modality indications
>>>>
>>>>             The combination of Language tags and other information
>>>>             in the media descriptions should be composed so that
>>>>             the intended modality can be concluded by the
>>>>             negotiating parties. The following combinations of
>>>>             language tags and media provide obvious information
>>>>             about the modality: sign language tags in video media
>>>>             indicate signed modality, spoken language tags for
>>>>             audio media indicate spoken modality and written
>>>>             language tags for text media indicate written modality.
>>>>             The examples in this specification are all from this
>>>>             set of three obvious language/media/modality combinations.
>>>>
>>>>             A sign language can be identified by the existence in
>>>>             the IANA registry of language subtags according to BCP
>>>>             47 [RFC5646] of the language subtag with the Type field
>>>>             "extlang" combined with the Prefix field value "sgn".
>>>>             A specific spoken or written language can be identified
>>>>             by not having any such "sgn" Prefix.
>>>>
>>>>             Use of language may appear in other media, such as
>>>>             "message" and "application". Video media may be used
>>>>             for other modalities than signed. Such use may be
>>>>             supported by further work or application specific
>>>>             agreements or indications for evaluation of the
>>>>             intended modality.
>>>>
>>>>             -------------------------------------------------------------------End
>>>>             of new text---------------------------------------
>>>>
>>>>             Den 2017-11-20 kl. 15:55, skrev Randall Gellens:
>>>>>             At 7:47 PM -0800 11/19/17, Bernard Aboba wrote:
>>>>>
>>>>>>              "So let's delete Section 5.4 and be done with it. 
>>>>>>             Neither of the statements is necessary."
>>>>>>
>>>>>>              [BA]  I agree that Section 5.4 does not add much
>>>>>>             value as it stands.
>>>>>>
>>>>>>              "Non-signed" is not used outside of Section 5.4, so
>>>>>>             there would not appear to be a need to define it if
>>>>>>             Section 5.4 were to be deleted.
>>>>>>
>>>>>>              However, the term "signed" is used in 7 other places
>>>>>>             in the document other than in Section 5.4.
>>>>>
>>>>>             But none of those instances are normative.
>>>>>
>>>>>>              So we may need to find a reference to define that term.
>>>>>
>>>>>             Because the uses of the term are descriptive and
>>>>>             mostly background, I do not think we need to add a
>>>>>             definition or even a reference to a definition of the
>>>>>             term.
>>>>>
>>>>>             --Randall
>>>>>
>>>>>>
>>>>>>              If Gunnar's suggested definition can be confirmed,
>>>>>>             this might be as simple as adding a reference to the
>>>>>>             IANA language tag repository.
>>>>>>
>>>>>>              On Sun, Nov 19, 2017 at 3:52 PM, Randall Gellens
>>>>>>             <<mailto:rg+ietf@randy.pensive.org>
>>>>>>             <mailto:rg+ietf@randy.pensive.org>rg+ietf@randy.pensive.org
>>>>>>             <mailto:rg+ietf@randy.pensive.org>> wrote:
>>>>>>
>>>>>>              My view of issue #43 remains that we do not need to
>>>>>>             specify a mechanism for determining which tags are
>>>>>>             signed.  In the email discussion of the past month or
>>>>>>             so, I fear we are drifting into adding complexity
>>>>>>             rather than removing it.  I think the way forward is
>>>>>>             to keep this document as simple as possible. As
>>>>>>             Bernard notes in his email of 10/23, there is no
>>>>>>             benefit in this case of explicitly saying that
>>>>>>             certain things are not defined. Since the document
>>>>>>             does not define them, they are undefined in the
>>>>>>             document.
>>>>>>
>>>>>>              At 6:51 PM -0700 10/23/17, Bernard Aboba wrote:
>>>>>>
>>>>>>               In other words,it is not clear to me how Section
>>>>>>             5.4's discussion of scope improves or clarifies the
>>>>>>             situation in any way - and there is some possibility
>>>>>>             that it could cause problems.
>>>>>>
>>>>>>
>>>>>>
>>>>>>              I believe comment #43 should be closed as no longer
>>>>>>             applicable, since the text against which it was
>>>>>>             generated has been deleted. (I've said this before,
>>>>>>             and I believe it remains the case.)
>>>>>>
>>>>>>              The comment from which #43 derives was made against
>>>>>>             a version of the document that had text explicitly
>>>>>>             discussing signed versus unsigned tags.  That text
>>>>>>             was subsequently deleted.
>>>>>>
>>>>>>              Here is the comment from which #43 derived:
>>>>>>
>>>>>>                  5.2.  New 'humintlang-send' and
>>>>>>             'humintlang-recv' attributes
>>>>>>
>>>>>>                  Note that while signed language tags are used
>>>>>>             with a video stream
>>>>>>               to
>>>>>>                  indicate sign language, a spoken language tag
>>>>>>             for a video stream
>>>>>>               in
>>>>>>                  parallel with an audio stream with the same
>>>>>>             spoken language tag
>>>>>>                  indicates a request for a supplemental video
>>>>>>             stream to see the
>>>>>>                  speaker.
>>>>>>
>>>>>>               And there's a similar paragraph in 5.4:
>>>>>>
>>>>>>                  A spoken language tag for a video stream in
>>>>>>             conjunction with an
>>>>>>
>>>>>>               audio
>>>>>>
>>>>>>                  stream with the same language might indicate a
>>>>>>             request for
>>>>>>                  supplemental video to see the speaker.
>>>>>>
>>>>>>
>>>>>>               I think this mechanism needs to be described more
>>>>>>             exactly, and in
>>>>>>               particular, it should not depend on the UA
>>>>>>             understanding which
>>>>>>               language tags are spoken language tags.  It seems
>>>>>>             to me that a
>>>>>>               workable rule is that there is an audio stream and
>>>>>>             a video stream and
>>>>>>               they specify exactly the same language tag in their
>>>>>>             respective
>>>>>>               humintlang attributes.  In that case, it is a
>>>>>>             request for a spoken
>>>>>>               language with simultaneous video of the speaker,
>>>>>>             and those requests
>>>>>>               should be considered satisfied only if both streams
>>>>>>             can be
>>>>>>               established.
>>>>>>
>>>>>>
>>>>>>              The offending text that was in 5.2 and 5.4 was deleted.
>>>>>>
>>>>>>              The only remaining text that even mentions the issue
>>>>>>             is Section 5.4:
>>>>>>
>>>>>>                 The behavior when specifying a non-signed
>>>>>>             language tag for a video
>>>>>>                 media stream, or a signed language tag for an
>>>>>>             audio or text media
>>>>>>                 stream, is not defined in this document.
>>>>>>
>>>>>>                 The problem of knowing which language tags are
>>>>>>             signed and which are
>>>>>>                 not is out of scope of this document.
>>>>>>
>>>>>>              So, let's delete Section 5.4 and be done with it.
>>>>>>             Neither of the statements is necessary.
>>>>>>
>>>>>>              --
>>>>>>              Randall Gellens
>>>>>>              Opinions are personal;    facts are suspect;    I
>>>>>>             speak for myself only
>>>>>>              -------------- Randomly selected tag: ---------------
>>>>>>              Make it right before you make it faster.
>>>>>
>>>>>
>>>>
>>>>             -- ----------------------------------------- Gunnar
>>>>             Hellström Omnitor gunnar.hellstrom@omnitor.se
>>>>             <mailto:gunnar.hellstrom@omnitor.se> +46 708 204 288
>>>>
>>>>
>>>
>>>         -- 
>>>         -----------------------------------------
>>>         Gunnar Hellström
>>>         Omnitor
>>>         gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
>>>         +46 708 204 288
>>>
>>>
>>>         _______________________________________________
>>>         SLIM mailing list
>>>         SLIM@ietf.org <mailto:SLIM@ietf.org>
>>>         https://www.ietf.org/mailman/listinfo/slim
>>>         <https://www.ietf.org/mailman/listinfo/slim>
>>
>>         -- 
>>         -----------------------------------------
>>         Gunnar Hellström
>>         Omnitor
>>         gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
>>         +46 708 204 288
>>
>>
>
>     -- 
>     -----------------------------------------
>     Gunnar Hellström
>     Omnitor
>     gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
>     +46 708 204 288
>
>

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