Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)

From: "Doug Ewell" <[email-masked]>
Date: Mon, 13 Feb 2017 16:10:00 -0700

Gunnar Hellström wrote:

> But captions overlayed on video in the media stream is a used
> technology so it would be good to be able to specify it.
> That we cannot do it is again a sad effect of the language tags not
> distinguishing between spoken and written modality.

se-Latn = Swedish written in Latin script
se-Cyrl = Swedish written in Cyrillic script
se-Maya = Swedish written in Mayan hieroglyphs

se-Zxxx = Swedish, explicitly not written

"se-Zxxx, fi-Latn" = content includes non-written Swedish plus Finnish
written in Latin script

Examples of multiple streams of content, such as video in one language
that is subtitled in another, call for multiple language tags. That is
not a shortcoming or failure of the language tag mechanism. See RFC
5646, Section 4.3.

All of this was discussed in the WG by the same parties.

> I once had an ambition to try to specify a notation for that to be
> added to BCP 47, but did not succeed to get any real discussion going
> on the topic. 
 
I searched the ietf-languages archives and did not find any sort of post
or proposal from you. I forwarded one of your messages from SLIM to that
list in November 2015, expecting you to follow up with a proposal, but
nothing materialized.
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 14 Feb 2017 08:06:14 +0100

Doug,

Thanks for pointing at the Zxxx script subtag for non-written content.

I think we can document the use of it for the view of a speaker in video 
media when indicated by a spoken/written language tag.

I have tried before to propose to use the script subtag to indicate 
written language, but got opposition because many languages have their 
main script subtag suppressed. However, the language around suppressed 
script subtags indicate that there are cases when the use is 
appropriate. We  can document that text captions in the video stream 
shall (or should) be indicated with a script subtag.

But, to keep it simple, the use of Zxxx scrit subtag on the view of a 
speaker should be sufficient.

That could conclude the unusual combinations:

1. Spoken/written tag in video media, can mean to see a speaking person, 
or to provide captions overlayed on video.

When the intention is to indicate overlayed captions in the video 
stream, the script subtag Zxxx SHALL be used.

Otherwise, a view of a speaking person is indicated.

2. Signed language tag in audio media,
means audio from a person using sign language, and SHOULD only be used 
for rare cases when it has some relevance for language communication.

3. Sign language tag in text media.

SHALL be used for any approximate text coded representation of sign 
language or fingerspelling.

I suggest that these conclusions form the base for a redefined section 5.4.

--------------------------------------------------------------------------
About my efforts to discuss modality in the language list: The list was 
closed when I tried to subscribe or send to it, and I did not see any 
response on a question I sent about how to get a discussion on the 
modality topic.

But I am happy now with your pointing out the Zxxx script. a 
spoken/written language with Zxxx script is quite obviously not written 
and not signed, so then it is spoken. Good.

Thanks

Gunnar

Den 2017-02-14 kl. 00:10, skrev Doug Ewell:
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 14 Feb 2017 11:01:45 +0100

My proposal for a reworded section 5.4 is:

5.4.  Unusual language indications

It is possible to specify an unusual indication where the language
specified may look unexpected for the media type.

For such cases the following guidance SHALL be applied for the 
humintlang attributes used in these situations.

 1. A view of a speaking person in the video stream SHALL, when it has
    relevance for speech perception, be indicated by a Language-Tag for
    spoken/written language with the "Zxxx" script subtag to indicate
    that the contents is not written.

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

 3. Any approximate representation of sign language or fingerspelling in
    the text media stream SHALL be indicated by a Language-Tag for a
    sign language in text media.

 4. When sign language related audio from a person using sign language
    is of importance for language communication, this SHALL be indicated
    by a Language-Tag for a sign language in audio media.

-------------------------------------------------------------------------------
This paragraph in 5.2 should be deleted because it is a duplication.

"   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."

Regards

Gunnar

Den 2017-02-14 kl. 08:06, skrev Gunnar Hellström:
> I think we can document the use of it for the view of a speaker in 
> video media when indicated by a spoken/written language tag.
>
> 1. Spoken/written tag in video media, can mean to see a speaking 
> person, or to provide captions overlayed on video.
>
> About my efforts to discuss modality in the language list: The list 
> was closed when I tried to subscribe or send to it, and I did not see 
> any response on a question I sent about how to get a discussion on the 
> modality topic.
>
> spoken/written language with Zxxx script is quite obviously not 
> written and not signed, so then it is spoken. Good.
>
> Thanks
>
> Gunnar
>
>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Feb 2017 09:40:11 -0800

At 11:01 AM +0100 2/14/17, Gunnar Hellström wrote:

>  For such cases the following guidance SHALL be 
> applied for the humintlang attributes used in 
> these situations.
>
>  1.	A view of a speaking person in the video 
> stream SHALL, when it has relevance for speech 
> perception, be indicated by a Language-Tag for 
> spoken/written language with the "Zxxx" script 
> subtag to indicate that the contents is not 
> written.
>
>  2.	Text captions included in the video 
> stream SHALL be indicated by a Language-Tag for 
> spoken/written language.
>
>  3.	Any approximate representation of sign 
> language or fingerspelling in the text media 
> stream SHALL be indicated by a Language-Tag for 
> a sign language in text media.
>
>  4.	When sign language related audio from a 
> person using sign language is of importance for 
> language communication, this SHALL be indicated 

[RG] As I said, I think we should avoid 
specifying this until we have deployment 
experience.

[RG] I agree and will delete the paragraph.

>>  I think we can document the use of it for the 
>> view of a speaker in video media when 
>> indicated by a spoken/written language tag.
>>
>>  I have tried before to propose to use the 
>> script subtag to indicate written language, 
>> but got opposition because many languages have 
>> their main script subtag suppressed. However, 
>> the language around suppressed script subtags 
>> indicate that there are cases when the use is 
>> appropriate. We  can document that text 
>> captions in the video stream shall (or should) 
>> be indicated with a script subtag.
>>
>>  But, to keep it simple, the use of Zxxx scrit 
>> subtag on the view of a speaker should be 
>> sufficient.
>>
>>  1. Spoken/written tag in video media, can mean 
>> to see a speaking person, or to provide 
>> captions overlayed on video.
>>
>>  When the intention is to indicate overlayed 
>> captions in the video stream, the script 
>> subtag Zxxx SHALL be used.
>>
>>  means audio from a person using sign language, 
>> and SHOULD only be used for rare cases when it 
>> has some relevance for language communication.
>>
>>  SHALL be used for any approximate text coded 
>> representation of sign language or 
>> fingerspelling.
>>
>>  About my efforts to discuss modality in the 
>> language list: The list was closed when I 
>> tried to subscribe or send to it, and I did 
>> not see any response on a question I sent 
>> about how to get a discussion on the modality 
>> topic.
>>
>>  But I am happy now with your pointing out the 
>> Zxxx script. a spoken/written language with 
>> Zxxx script is quite obviously not written and 
>> not signed, so then it is spoken. Good.
>>
>>  Thanks
>>
>>  Gunnar
>>
>>
>>>  <mailto:[email-masked]>[email-masked]
>>> 
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>
>  --
>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288
>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If you would look up bad labor relations in the dictionary, you
would have an American Airlines logo beside it.
    --U.S. District Judge Joe Kendall, issuing a restraining order
against an American Airlines APA pilot union sick out, 10 Feb 1999.

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 14 Feb 2017 20:59:12 +0100

Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:

> Hi -
>
> On 2/14/2017 9:40 AM, Randall Gellens wrote:
>>>  1.    A view of a speaking person in the video stream SHALL, when it
>>> has relevance for speech perception, be indicated by a Language-Tag
>>> for spoken/written language with the "Zxxx" script subtag to indicate
>>>  2.    Text captions included in the video stream SHALL be indicated
>>> by a Language-Tag for spoken/written language.
>>>
>>>  3.    Any approximate representation of sign language or
>>> fingerspelling in the text media stream SHALL be indicated by a
>>> Language-Tag for a sign language in text media.
>>>
>>>  4.    When sign language related audio from a person using sign
>>> language is of importance for language communication, this SHALL be
>>> indicated by a Language-Tag for a sign language in audio media.
>>
>> [RG] As I said, I think we should avoid specifying this until we have
>> deployment experience.
> ...
>
> From a process perspective, it's far easier to remove constraints
> as a specification advances than it is to add them.
I agree. It is often better to specify normatively as far as you can 
imagine, so that interoperability and good functionality is achieved. 
Stopping halfway and have MAY in the specifications creates uncertainty 
and less useful specifications.

Furthermore, in this case we succeeded to discuss and sort out the 
interpretation of the unusual combinations.
I am very glad that we sorted out the difference between 1 and 2, and 
they are both real-life cases.

3 is not at all common, but I have seen products claiming to work for 
real-time communication with sign representation in text. So it is good 
to have it settled.

4. Is a bit more far fetched and may cause some questioning if there are 
real cases, and where the line should be drawn between indicating a 
spoken languge in the audio stream and indicating a sign language in the 
audio stream.
As I wiew it now, this combination will be very rare, but it is anyway 
good to be specific and normative about its coding.

Gunnar

> Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 14 Feb 2017 20:39:55 +0000

I have some allergy to the SHALL language: there is no way to automatically determine conformance. Many language tags represent nonsensical values, due to the nature of language tag composition. Content providers need to use care in selecting the tags that they use and this section is merely pointing out good guidance for tag selection, albeit in a heavy-handed way. BCP47 RFC 5646 Section 4.1 [1] already provides most of this guidance and a reference to that source might be useful here, if only because that document requires it:

<quote>
   Standards, protocols, and applications that reference this document
   normatively but apply different rules to the ones given in this
   section MUST specify how language tag selection varies from the
   guidelines given here.
</quote>

I would suggest reducing the SHALL items to SHOULD.

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.

Regards,

Addison

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

[1] https://tools.ietf.org/html/bcp47#section-4.1

-----Original Message-----
From: SLIM [mailto:[email-masked]] On Behalf Of Gunnar Hellström
Sent: Tuesday, February 14, 2017 11:59 AM
To: Randy Presuhn <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)

Den 2017-02-14 kl. 19:05, skrev Randy Presuhn:

>>> for spoken/written language with the "Zxxx" script subtag to 
>>> indicate that the contents is not written.
>>>
> From a process perspective, it's far easier to remove constraints as a 
> specification advances than it is to add them.
I agree. It is often better to specify normatively as far as you can imagine, so that interoperability and good functionality is achieved. 
Stopping halfway and have MAY in the specifications creates uncertainty and less useful specifications.

Furthermore, in this case we succeeded to discuss and sort out the interpretation of the unusual combinations.
I am very glad that we sorted out the difference between 1 and 2, and they are both real-life cases.

3 is not at all common, but I have seen products claiming to work for real-time communication with sign representation in text. So it is good to have it settled.

4. Is a bit more far fetched and may cause some questioning if there are real cases, and where the line should be drawn between indicating a spoken languge in the audio stream and indicating a sign language in the audio stream.
As I wiew it now, this combination will be very rare, but it is anyway good to be specific and normative about its coding.

Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Feb 2017 14:35:02 -0800

> subtag to indicate that the contents is not 

What does "relevance for speech perception" mean 
in the spec, and how is it determined?

> stream SHALL be indicated by a Language-Tag for 

Is this commonly supported such that it makes 
sense to include in the current draft?  Perhaps 
it should wait for an update that might include 
similar functionality such as text captions for 
audio streams.

> a sign language in text media.

Same comment as for (2).

> by a Language-Tag for a sign language in audio 

Same comment as for (1).

-------------- Randomly selected tag: ---------------
They say that 90 per cent of TV is junk.  But 90 per cent
of *everything* is junk.
      --Gene Roddenberry, interview in TV Guide, Apr. 27, 1974
      (quoting Sturgeon's Revelation: "Ninety percent of
      everything is crap.")

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Feb 2017 14:39:50 -0800

>  as a specification advances than it is to add them.

Which supports the text I proposed on Monday:

    Specifying a non-signed language tag for a video media stream, or a
    signed language tag for a non-video media stream, is not defined.  An
    offer with such a combination SHOULD NOT be created.  If such an
    offer is received, the receiver MAY ignore the language specified.

This proposed text has a mild constraint to not 
include such combinations.  By using "SHOULD NOT" 
and "MAY" we allow cooperating implementations to 
use it without imposing semantic implications now 
that might not be what we need in the future. 
After we have some experience, we can either use 
the existing attributes and language tags to 
impose meanings as Gunnar suggests, or we might 
find we need a different mechanism that has more 
functionality.

-------------- Randomly selected tag: ---------------
The solution to a problem changes the nature of the problem.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Feb 2017 14:43:34 -0800

At 8:59 PM +0100 2/14/17, Gunnar Hellström wrote:

>  I agree. It is often better to specify 
> normatively as far as you can imagine, so that 
> interoperability and good functionality is 
> achieved. Stopping halfway and have MAY in the 
> specifications creates uncertainty and less 
> useful specifications.

My reading of what Randy says is the opposite of 
Gunnar's.  In my reading, Randy points out that 
is it easier to remove the SHOULD NOT in the 
future then it is to change the meaning of the 
combinations or switch to a different mechanism.

In my experience, it's better to specify only 
what we know we need and what we know we 
understand.  Speculative specifications "as far 
as you can imagine" more often lead to 
interoperability problems, unnecessary 
complexity, limitations on what's needed in the 
future, and divergent implementations.

>
>  Furthermore, in this case we succeeded to 
> discuss and sort out the interpretation of the 
> unusual combinations.
>  I am very glad that we sorted out the 
> difference between 1 and 2, and they are both 
> real-life cases.
>
>  3 is not at all common, but I have seen 
> products claiming to work for real-time 
> communication with sign representation in text. 
> So it is good to have it settled.
>
>  4. Is a bit more far fetched and may cause some 
> questioning if there are real cases, and where 
> the line should be drawn between indicating a 
> spoken languge in the audio stream and 
> indicating a sign language in the audio stream.
>  As I wiew it now, this combination will be very 
> rare, but it is anyway good to be specific and 
> normative about its coding.

-------------- Randomly selected tag: ---------------
A day for firm decisions!!!!!  Or is it?

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 14 Feb 2017 16:21:35 -0800

Hi -

On 2/14/2017 2:43 PM, Randall Gellens wrote:
>> Stopping halfway and have MAY in the specifications creates
>> uncertainty and less useful specifications.
>
> My reading of what Randy says is the opposite of Gunnar's.  In my
> reading, Randy points out that is it easier to remove the SHOULD NOT in
> the future then it is to change the meaning of the combinations or
> switch to a different mechanism.
>
> In my experience, it's better to specify only what we know we need and
> what we know we understand.  Speculative specifications "as far as you
> can imagine" more often lead to interoperability problems, unnecessary
> complexity, limitations on what's needed in the future, and divergent
> implementations.

I think the difference in your positions comes down to

   (1) your respective notions of "what we know we need and what we
       know we understand";

   (2) whether you believe that the interoperability and conformance
       consequences of removing a "SHOULD NOT" could be the same
       as those merely retaining a "MUST" or "SHALL" - this determines
       whether Randy G.'s proposal provides a path for some future
       revision to mandate (if deployment experience substantiates the
       need/understanding) the behavior proposed by Gunnar.  That path
       is not at all obvious to me.

Randy

---

From: Randall Gellens <[email-masked]>
Date: Tue, 14 Feb 2017 16:39:21 -0800

>        is not at all obvious to me.

The purpose of the draft is to enable the two 
endpoints of a real-time communication session to 
agree which languages and media to use for 
interactive communication.  We have a mechanism 
of adding language tags to media stream 
negotiations.  In most cases, the language and 
media modality are an obvious fit.  There are 
combinations of media and language where the 
meaning is not so obvious, specifically, signed 
language tags with a audio or text, and 
non-signed language tags with video.  My proposal 
is that we say offerer SHOULD NOT send such 
combinations and answerer MAY ignore language. 
This allows future specifications for the 
underlying uses Gunnar wants (such as real-time 
subtitles in video and signed equivalents in 
text).  Such future specifications could define a 
use for the language and media combinations and 
remove the SHOULD NOT send and MAY ignore, or 
could define a new mechanism.  I don't think we 
know enough now to dictate what the solution 
should be.

-------------- Randomly selected tag: ---------------
Dogs have owners.  Cats have staff.

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 15 Feb 2017 10:41:00 +0100

Den 2017-02-15 kl. 01:39, skrev Randall Gellens:
> The purpose of the draft is to enable the two endpoints of a real-time 
> communication session to agree which languages and media to use for 
> interactive communication.  We have a mechanism of adding language 
> tags to media stream negotiations.  In most cases, the language and 
> media modality are an obvious fit.  There are combinations of media 
> and language where the meaning is not so obvious, specifically, signed 
> language tags with a audio or text, and non-signed language tags with 
> video.  My proposal is that we say offerer SHOULD NOT send such 
> combinations and answerer MAY ignore language. This allows future 
> specifications for the underlying uses Gunnar wants (such as real-time 
> subtitles in video and signed equivalents in text).  Such future 
> specifications could define a use for the language and media 
> combinations and remove the SHOULD NOT send and MAY ignore, or could 
> define a new mechanism.  I don't think we know enough now to dictate 
> what the solution should be.
We have a fresh example from our own discussions in the SLIM group how 
unfortunate it is to not be sufficiently explicit in the first edition 
of a standard. The SDP Lang attribute in RFC 4566, where you (Randall) 
say it is intended for specifying a set of languages that all must be 
used in a session, while I say that it is intended for negotiation of at 
least one initial language. By having that uncertainty in a 
specification that has been published makes it very hard to sharpen up 
the specification afterwards because it would possibly make some 
implementations non conformant. And it makes potential implementors 
hesitant to use the current specifications, as it was with the SLIM work.

For 5.4.

I am OK with modifying from my latest proposal, but we need to be specific.
I am also OK with reducing the SHALLs to SHOULDs as Addison requested.

The situation is not that we lack knowledge. Here is what we know about 
the 4 cases of "unusual" indications:

1. View of the speaker in video. Very important for speech perception. 
Quality requirements are documented in ITU-T H-series Supplement 1. Of 
real use only as a complement to the same spoken language in audio. Now, 
when we know about the Zxxx notation for non-written, we also have a 
good way of specifying it precisely.
This case was also described in section 5.2 already.

2. Text captions in the video stream.
This can be either text merged into video and communicated as true part 
of the video image, or it can be a text component of a multimedia 
system, as MPEG-4, declared in SDP as m=video.
It has been used in some videophone products, but I have not seen it 
used lately.
It is a clearly defined case, and we can specify coding for it, but we 
do not at the moment know if it will be important to specify it.

3. Sign language or fingerspelling in the text stream.
I have seen a product using it for claimed sign language conversation. 
It is also in use in the simple text form with words in capitals 
approximately representing signs between persons involved in preparation 
of sign language productions and translations. But in that case it is in 
a session where they agree in other ways to start using the text stream 
for that purpose. So I think we can say that this is rare, and its use 
can be agreed by other means between the users. Still it is a clearly 
defined case.

4. Audio from signing person related to sign language. This is more 
vague than the others.  It may be a person signing in video and adding 
spoken words in audio to signing, but influenced by the word order and 
grammar of sign language with some ambition to make it reasonably 
understandable for both deaf and hearing participants. There are even 
some spoken words created from sign language that are commonly used by 
hearing persons in such situations. But for that case I anyway think it 
is better to define the audio part as the spoken language it is derived 
from, because of its intention to be understandable for hearing persons. 
All other variants I can imagine are even closer to the spoken language 
and should be specified with spoken language tag. If we only want to 
have the audio stream established to hear the background in the signing 
situation, then we should not specify language use of the audio stream.
Even if we know what sign language tag in audio stream would be, it may 
be just as good to leave it undefined.
------------------------------------------------------------------------------------------------------------------------------------------------
So, new proposal:

    For such cases the following guidance SHOULD be applied for the
   humintlang attributes used in these situations.

    1.    A view of a speaking person in the video stream SHOULD, when it
   has relevance for speech perception, be indicated by a humintlang 
attribute with a Language-Tag
   for a spoken/written language with the "Zxxx" script subtag to indicate
   that the contents is not written.

    2.    Text captions included in the video stream SHOULD be indicated
   by a humintlang attribute with Language-Tag for spoken/written language.

    3.    A Language-Tag for a sign language specified in a humintlang 
attribute for a text stream MAY be interpreted as use of an approximate 
representation of sign language or fingerspelling in the text media 
stream. The use of such representation is rare and usually conveniently 
agreed by other means between the users during an established session. 
Common support of this indication SHOULD NOT be assumed or required.

    4.    A Language-Tag for a sign language specified in a humintlang 
attribute for an audio stream SHOULD NOT be indicated and MAY be ignored 
on reception. Any use of spoken words or spoken language in the audio 
stream SHOULD, when it can be of importance for language communication, 
be indicated by the corresponding Language-Tag for spoken language in a 
humintlang attribute for the audio stream.

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 15 Feb 2017 11:07:46 +0100

Addison,

> I would suggest reducing the SHALL items to SHOULD.
Accepted.
That also opens up for another use we have discussed before but been 
advised to not use. That is to indicate use of written language by 
attaching a script subtag even if the script subtag we use is suppressed 
by BCP 47. We can dro that need however, with the use of the Zxxx script 
subtag for non-written, and clearly include that usage in our 
specification as required from BCP 47.
> I'm not sure what #2 really means. Shouldn't text captions be indicated by the written language rather than the spoken language? And I'm not sure what "spoken/written language" means.
#2 was: "

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

Yes, the intention is to use written language in the video stream. There 
are technologies for that.
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.
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.
Since we have the script subtag Zxxx for non-written, we do not need to 
construct an explicit tag for the written language tag, it should be 
sufficient with our specification of the use in our case.

In my latest recent proposal, I still have a very similar wording. Since 
you had problems understanding it, there might still be a need to tune 
it. Can you propose wording?
This is the current proposal:

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

Regards
Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 15 Feb 2017 13:32:56 +0100

in issue 8, I propose:

(Look in the edited draft -06g that I attached some days ago for how the 
proposal appears in the text )

------------------------------------------------------------------------------------------------------------ 

8. Include more fields for attribute registration from 4566bis

Section 6 has the form for attribute registration by IANA. There are a 
couple of fields missing that will be important for use of the 
specification in the WebRTC environment.  Include these fields if that 
is allowable according to current IANA procedures and if that does not 
delay the publication of this draft. These fields are needed for use of 
text media in WebRTC.

Change:

In two locations from:
     "Usage Level:  media"

to:

     "Usage Level:  media, dcsa(subprotocol)"

Insert in two locations in the registration forms:
"Mux Category: NORMAL"
---------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------

I checked in current IANA registrations, and found that all SDP 
attribute registrations now include the "Mux Category".

So, I assume that we are obliged to do so also and hope that we can 
agree on that.
As far as I understand the logic, we should specify NORMAL.

I saw no trace yet of registrations of  "Usage Level: dcsa(subprotocol)"

I would like to get advice from someone with insight in the SDP 
attribute registration and the status of the dsca(subprotocol) value on 
how we should proceed in order to get the dsca(subprotocol)  included in 
a smooth way without causing exessive delay.

Regards
Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 15 Feb 2017 13:45:12 +0100

More info below.

Den 2017-02-15 kl. 13:32, skrev Gunnar Hellström:
> in issue 8, I propose:
>
> (Look in the edited draft -06g that I attached some days ago for how 
> the proposal appears in the text )
>
>
> delay the publication of this draft. These fields are needed for use 
> of text media in WebRTC.
>
> Change:
>
> In two locations from:
>     "Usage Level:  media"
>
> to:
>
> attribute registration and the status of the dsca(subprotocol) value 
> on how we should proceed in order to get the dsca(subprotocol)  
> included in a smooth way without causing exessive delay.
I found in 
https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-11#section-8.3 
that the registration of dcsa(subprotocol)  seems to require a specific 
actual subprotocol. That is further away in time, and if that conclusion 
is right, we need to include MUX Category but exclude "Usage Level: 
dcsa(subprotocol)"  from the registration.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 15 Feb 2017 08:18:12 -0800

At 10:41 AM +0100 2/15/17, Gunnar Hellström wrote:

>> endpoints of a real-time communication session 
>> to agree which languages and media to use for 
>> interactive communication.  We have a 
>> mechanism of adding language tags to media 
>> stream negotiations.  In most cases, the 
>> language and media modality are an obvious 
>> fit.  There are combinations of media and 
>> language where the meaning is not so obvious, 
>> specifically, signed language tags with a 
>> audio or text, and non-signed language tags 
>> with video.  My proposal is that we say 
>> offerer SHOULD NOT send such combinations and 
>> answerer MAY ignore language. This allows 
>> future specifications for the underlying uses 
>> Gunnar wants (such as real-time subtitles in 
>> video and signed equivalents in text).  Such 
>> future specifications could define a use for 
>> the language and media combinations and remove 
>> the SHOULD NOT send and MAY ignore, or could 
>> define a new mechanism.  I don't think we know 
>> enough now to dictate what the solution should 
>> be.
>  We have a fresh example from our own 
> discussions in the SLIM group how unfortunate 
> it is to not be sufficiently explicit in the 
> first edition of a standard. The SDP Lang 
> attribute in RFC 4566, where you (Randall) say 
> it is intended for specifying a set of 
> languages that all must be used in a session, 
> while I say that it is intended for negotiation 
> of at least one initial language. By having 
> that uncertainty in a specification that has 
> been published makes it very hard to sharpen up 
> the specification afterwards because it would 
> possibly make some implementations non 
> conformant. And it makes potential implementors 

I don't believe the two cases are comparable. 
The original SDP language attribute was unclear 
how it was used.  The new attributes specified in 
the current draft are clearly defined for the set 
of cases that has been the target solution space 
all along: allowing the two sides to agree on 
which language will be used in interactive 
communications.  You want to extend them for a 
related solution space, which is additional 
services to foster communication, such as adding 
real-time captioning to video.  I think it's 
better to do that add-on work in a subsequent 
draft.

>  The situation is not that we lack knowledge. 
> Here is what we know about the 4 cases of 
> "unusual" indications:
>
>  1. View of the speaker in video. Very important 
> for speech perception. Quality requirements are 
> documented in ITU-T H-series Supplement 1. Of 
> real use only as a complement to the same 
> spoken language in audio. Now, when we know 
> about the Zxxx notation for non-written, we 
> also have a good way of specifying it precisely.

It's already possible to negotiate a video stream.

>  This can be either text merged into video and 
> communicated as true part of the video image, 
> or it can be a text component of a multimedia 
>  It has been used in some videophone products, 
> but I have not seen it used lately.
>  It is a clearly defined case, and we can 
> specify coding for it, but we do not at the 
> moment know if it will be important to specify 
> it.

I believe this is an additional service that 
should be specified in a subsequent draft.

>  I have seen a product using it for claimed sign 
> language conversation. It is also in use in the 
> simple text form with words in capitals 
> approximately representing signs between 
> persons involved in preparation of sign 
> language productions and translations. But in 
> that case it is in a session where they agree 
> in other ways to start using the text stream 
> for that purpose. So I think we can say that 
> this is rare, and its use can be agreed by 
> other means between the users. Still it is a 
> clearly defined case.

I believe this is an additional service that 
should be specified in a subsequent draft.

>
>  4. Audio from signing person related to sign 
> language. This is more vague than the others. 
> It may be a person signing in video and adding 
> spoken words in audio to signing, but 
> influenced by the word order and grammar of 
> sign language with some ambition to make it 
> reasonably understandable for both deaf and 
> hearing participants. There are even some 
> spoken words created from sign language that 
> are commonly used by hearing persons in such 
> situations. But for that case I anyway think it 
> is better to define the audio part as the 
> spoken language it is derived from, because of 
> its intention to be understandable for hearing 
> persons. All other variants I can imagine are 
> even closer to the spoken language and should 
> be specified with spoken language tag. If we 
> only want to have the audio stream established 
> to hear the background in the signing 
>  Even if we know what sign language tag in audio 
> stream would be, it may be just as good to 
> leave it undefined.

I believe this is an additional service that 
should be specified in a subsequent draft.

>    has relevance for speech perception, be 
> indicated by a humintlang attribute with a 
> Language-Tag
>     3.    A Language-Tag for a sign language 
> specified in a humintlang attribute for a text 
> stream MAY be interpreted as use of an 
> approximate representation of sign language or 
> fingerspelling in the text media stream. The 
> use of such representation is rare and usually 
> conveniently agreed by other means between the 
> users during an established session. Common 
> support of this indication SHOULD NOT be 
> assumed or required.
>
>     4.    A Language-Tag for a sign language 
> specified in a humintlang attribute for an 
> audio stream SHOULD NOT be indicated and MAY be 
> ignored on reception. Any use of spoken words 
> or spoken language in the audio stream SHOULD, 
> when it can be of importance for language 
> communication, be indicated by the 
> corresponding Language-Tag for spoken language 
> in a humintlang attribute for the audio stream.
>
>
>
>
>  Gunnar
>
>
>  --

-------------- Randomly selected tag: ---------------
Think airlines.  Here a durable competitive advantage has proven
elusive ever since the days of the Wright Brothers.  Indeed, if a
farsighted capitalist had been present at Kitty Hawk, he would have
done his successors a huge favor by shooting Orville down.
        --"Oracle of Omaha," Warren Buffett

---

From: Randall Gellens <[email-masked]>
Date: Wed, 15 Feb 2017 08:26:56 -0800

At 1:32 PM +0100 2/15/17, Gunnar Hellström wrote:

>  in issue 8, I propose:
>
>  (Look in the edited draft -06g that I attached 
> some days ago for how the proposal appears in 
> the text )
>
>
> 
>  Section 6 has the form for attribute 
> registration by IANA. There are a couple of 
> fields missing that will be important for use 
> of the specification in the WebRTC environment. 
> Include these fields if that is allowable 
> according to current IANA procedures and if 
> that does not delay the publication of this 
> draft. These fields are needed for use of text 
> media in WebRTC.
>
>  Change:
>
>  In two locations from:
>      "Usage Level:  media"
>
>  to:
>
>  I checked in current IANA registrations, and 
> found that all SDP attribute registrations now 
> include the "Mux Category".
>
>  So, I assume that we are obliged to do so also 
> and hope that we can agree on that.

This is not required.  See the IANA registry at 
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml. 
It is governed by RFC 4566.

As I've written twice before, my concern is that 
this suggestion exceeds a simple editorial 
change, and therefore may need to be discussed on 
the WG list with WG consensus before it can be 
adopted.  These fields can be added to the 
attribute registration later, according to the 
rules for the registry 
(http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml).

>  I would like to get advice from someone with 
> insight in the SDP attribute registration and 
> the status of the dsca(subprotocol) value on 
> how we should proceed in order to get the 
> dsca(subprotocol)  included in a smooth way 
> without causing exessive delay.

-------------- Randomly selected tag: ---------------
Asking if computers can think is like asking if submarines can swim.

---

From: "Phillips, Addison" <[email-masked]>
Date: Wed, 15 Feb 2017 17:12:44 +0000

Gunnar replied:
> > I have some allergy to the SHALL language: there is no way to automatically
> determine conformance. Many language tags represent nonsensical values, due
> to the nature of language tag composition. Content providers need to use care
> in selecting the tags that they use and this section is merely pointing out good
> guidance for tag selection, albeit in a heavy-handed way. BCP47 RFC 5646
> Section 4.1 [1] already provides most of this guidance and a reference to that
> source might be useful here, if only because that document requires it:
> >
> > <quote>
> That also opens up for another use we have discussed before but been advised
> to not use. That is to indicate use of written language by attaching a script
> subtag even if the script subtag we use is suppressed by BCP 47. We can dro that
> need however, with the use of the Zxxx script subtag for non-written, and clearly
> include that usage in our specification as required from BCP 47.

I don't necessarily think that mandating a script subtag as a signal of written content (vs. spoken content) is that useful. In most protocols, the written nature of the content is indicated by the presence of text. Trying to coerce the language modality via language tags seems complicated, especially since most language tags are harvested from the original source. Introducing processes to evaluate and insert or remove script subtags seems unnecessary to me. That said, I have no objection to content using script subtags if they are useful. 

> >
> > I'm not sure what #2 really means. Shouldn't text captions be indicated by the
> written language rather than the spoken language? And I'm not sure what
> "spoken/written language" means.
> #2 was: "
> 
> 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."

> 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.

> language, because the same tag could in another context mean a spoken

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'"

> construct an explicit tag for the written language tag, it should be sufficient with
> our specification of the use in our case.

In case it isn't clear aboe, I oppose introducing the 'Zxxx' subtag save for cases where the non-written nature of the content is super-important to the identification of the language.
> 
> In my latest recent proposal, I still have a very similar wording. Since you had
> problems understanding it, there might still be a need to tune it. Can you
> propose wording?

I did that above. I think it is useful not to over-think it. When I see "Content-Type: video/mpeg; Content-Language: en-GB", I rather expect audio content in English and not written content (although the video stream might also includes pictures of English text such as the titles in a movie). When, as in this case, setting up a negotiated language experience, interoperability is most aided by matching the customer's language preferences to available resources. This is easiest when customers do not get carried away with complex language tags (ranges in BCP 47 parlance, e.g. tlh-Cyrl-AQ-fonupa) and systems do not have to introspect the language tags, inserting and removing script subtags to match the various language modes.

Addison

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Feb 2017 12:30:37 -0500

On 2/15/17 11:26 AM, Randall Gellens wrote:

> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml. It
> is governed by RFC 4566.
>
> As I've written twice before, my concern is that this suggestion exceeds
> a simple editorial change, and therefore may need to be discussed on the
> WG list with WG consensus before it can be adopted.  These fields can be
> added to the attribute registration later, according to the rules for
> the registry

The mux-category is a big deal. There is a document in progress that 
defines the mux-category for all existing attributes. Attributes defined 
after that need to define their mux-category. There is potentially a 
problem with attributes defined while this work is in progress. That 
document for old attributes isn't going to chase after ones defined 
concurrently. I think you will find that if you don't define this then 
it will be caught and requested either by a sdp-directorate review, or 
else the iesg review. So just do it!

>> included in a smooth way without causing exessive delay.

So far there has been *no* interest in defining RTP over SCTP. 
Until/unless that is defined there is no need to define dcsa for this 
attribute.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 15 Feb 2017 22:36:24 +0100

Addison,

> I don't necessarily think that mandating a script subtag as a signal of written content (vs. spoken content) is that useful. In most protocols, the written nature of the content is indicated by the…
In this case we are negotiating use of media streams before they are 
established, so that the connection will be made between best capable 
devices and call participants. There is no indication in the media 
coding parameters available to tell if text will be carried in video.  
So, if we want to be able to specify the three modalities possible in 
video we needto have differentiated notations for them: 1. view of a 
signing person, 2. view of a speaking person, 3. Text.      For 1. the 
signing person, it is simple, because the language subtags are explicit 
in that they indicate sign language. But for the two others I was not 
aware of any useful way before I was informed about the Zxxx script subtag.
Now, the reasoning about the need for these to be possible to 
distinguish caused me to specify that for the view of the signing person 
we use the Zxxx script subtag and for any text we do not need to specify 
any script subtag.
The view of the speaking person is the only very important alternative 
of the four identified "silly states", and that was already included in 
section 5.2. But both Bernard and I wanted to see the "silly states" 
chapter sharpened up and real alternatives sorted out and specified.
> 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."
Yes, that is a way to avoid mentioning spoken/written that apparently is 
confusing when the subtag in this case is used for written modality.
> The language subtags are for languages--all modalities. My comment here is that "spoken/written" adds no information.
Spoken/written is different from signed that is the "normal" modality 
for video.
> In case it isn't clear aboe, I oppose introducing the 'Zxxx' subtag save for cases where the non-written nature of the content is super-important to the identification of the language.
There is a possible alternative in RFC 4796, the SDP Content attribute, 
where "speaker" can be identified.  But that does not easily allow for 
describing alternative use of video for sign language or view of a 
speaking person.

So, the alternative to using Zxxx is as I see it to not be able to 
specify text in the video stream. Good interoperability of text in the 
text stream is so much more important so I am prepare to go that way if 
it is needed. Bernards view would be interesting here.
> I did that above. I think it is useful not to over-think it. When I see "Content-Type: video/mpeg; Content-Language: en-GB", I rather expect audio content in English and not written content (althou…
/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Wed, 15 Feb 2017 15:01:05 -0800

Hi Addison,

Please see in-line.

At 5:12 PM +0000 2/15/17, Addison Phillips wrote:

>  I don't necessarily think that mandating a script subtag as a 
> signal of written content (vs. spoken content) is that useful. In 
> most protocols, the written nature of the content is indicated by 
> the presence of text. Trying to coerce the language modality via 
> language tags seems complicated, especially since most language 
> tags are harvested from the original source. Introducing processes 
> to evaluate and insert or remove script subtags seems unnecessary 
> to me. That said, I have no objection to content using script 
> subtags if they are useful.
>
>>  >
>  I'm aware of that. My concern is that in this case "spoken/written" 
> is applied to "text captions", which are not spoken be definition? 
> This section is talking about the differences between identifying 
> spoken and written language. The text captions fall into the 
> written side of the equation, no?

Keep in mind that the focus of the draft is enabling language 
negotiation along with media negotiation for interactive 
communications.  In this context, as I noted in previous replies, 
real-time text captions for sign language in video is a service.  A 
mechanism for requesting services needs to be carefully thought out 
in the WG and not added to the current draft at the last minute.

>
>  I'd probably prefer to see something like "2. Text captions 
> included in the video stream SHOULD include a Language-Tag to 
> identify the language."
>
>> spoken/written
>  The language subtags are for languages--all modalities. My comment 
> here is that "spoken/written" adds no information.
>
>  One uses a Language-Tag for indicating the language. When the text 
> is written, sometimes the user will pick a different language tag 
> (zh-Hant-HK) than they might choose for spoken text (yue-HK, 
> zh-cmn-HK, etc.). Sometimes (actually, nearly all the time except 
> for special cases) the language tag for the spoken and written 
> language is the same tag (en-US, de-CH, ja-JP, etc.). Again, the 
> modality of the language is a separate consideration from the 
> language. Nearly always, it is better to use the same tag for both 
> spoken and written content rather than trying to use the tag to 
> distinguish between them: different Content-Types require different 
> decoders anyway, but it is really useful to say "give me all of the 
> 'en-US' content you have" or "do you have content for a user who 
> speaks 'es'"

Requesting all content available in a specific language is outside 
the scope of the draft, which is enabling language negotiation along 
with media negotiation for interactive communications.  One key 
example is a user placing an emergency call.  The call setup can 
negotiate both language and media for interactive communication 
between the emergency services answering point and the user.

>  In case it isn't clear aboe, I oppose introducing the 'Zxxx' subtag 
> save for cases where the non-written nature of the content is 
> super-important to the identification of the language.
>>
>  I did that above. I think it is useful not to over-think it. When I 
> see "Content-Type: video/mpeg; Content-Language: en-GB", I rather 
> expect audio content in English and not written content (although 
> the video stream might also includes pictures of English text such 
> as the titles in a movie). When, as in this case, setting up a 
> negotiated language experience, interoperability is most aided by 
> matching the customer's language preferences to available 
> resources. This is easiest when customers do not get carried away 
> with complex language tags (ranges in BCP 47 parlance, e.g. 
> tlh-Cyrl-AQ-fonupa) and systems do not have to introspect the 
> language tags, inserting and removing script subtags to match the 
> various language modes.
>
>  Addison
>

-------------- Randomly selected tag: ---------------
The First Amendment is often inconvenient. But that is besides the
point.  Inconvenience does not absolve the government of its
obligation to tolerate speech. --Justice Anthony Kennedy, in 91-155

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 15 Feb 2017 15:52:42 -0800

Gunnar Hellstrom said:

"The SDP Lang attribute in RFC 4566, where you (Randall) say it is intended
for specifying a set of languages that all must be used in a session, while
I say that it is intended for negotiation of at least one initial language."

[BA] At IETF 96 in Berlin, we had a discussion of the history of the SDP
Lang attribute within the MMUSIC WG.

The Lang attribute was originally specified in RFC 2327, which was
published in April 1998, more than four years prior to the publication of
Offer/Answer RFC 3264 (June 2002), and three years prior to publication of
the initial draft-rosenberg-mmusic-sdp-offer-answer-00 (April 26, 2001).

As a result, the Lang attribute could not have been designed for use in
Offer/Answer negotiation, but instead was intended for use in the
declarative SDP of multicast conferencing.  Note that the Lang attribute
was not mentioned in RFC 3264, and noone at the MMUSIC WG session was aware
of a subsequent SIP Offer/Answer implementation of it.

On Wed, Feb 15, 2017 at 1:41 AM, Gunnar Hellström <
[email-masked]> wrote:

>> interactive communication.  We have a mechanism of adding language tags to
>> media stream negotiations.  In most cases, the language and media modality
>> are an obvious fit.  There are combinations of media and language where the
>> meaning is not so obvious, specifically, signed language tags with a audio
>> or text, and non-signed language tags with video.  My proposal is that we
>> say offerer SHOULD NOT send such combinations and answerer MAY ignore
>> language. This allows future specifications for the underlying uses Gunnar
>> wants (such as real-time subtitles in video and signed equivalents in
>> text).  Such future specifications could define a use for the language and
>> media combinations and remove the SHOULD NOT send and MAY ignore, or could
>> define a new mechanism.  I don't think we know enough now to dictate what
>> the solution should be.
>>
> unfortunate it is to not be sufficiently explicit in the first edition of a
> standard. The SDP Lang attribute in RFC 4566, where you (Randall) say it is
> intended for specifying a set of languages that all must be used in a
> session, while I say that it is intended for negotiation of at least one
> initial language. By having that uncertainty in a specification that has
> been published makes it very hard to sharpen up the specification
> afterwards because it would possibly make some implementations non
> conformant. And it makes potential implementors hesitant to use the current
> specifications, as it was with the SLIM work.
>
> For 5.4.
>
> Quality requirements are documented in ITU-T H-series Supplement 1. Of real
> use only as a complement to the same spoken language in audio. Now, when we
> know about the Zxxx notation for non-written, we also have a good way of
> specifying it precisely.
> This can be either text merged into video and communicated as true part of
> the video image, or it can be a text component of a multimedia system, as
> MPEG-4, declared in SDP as m=video.
> It has been used in some videophone products, but I have not seen it used
> lately.
> It is a clearly defined case, and we can specify coding for it, but we do
> not at the moment know if it will be important to specify it.
>
> I have seen a product using it for claimed sign language conversation. It
> is also in use in the simple text form with words in capitals approximately
> representing signs between persons involved in preparation of sign language
> productions and translations. But in that case it is in a session where
> they agree in other ways to start using the text stream for that purpose.
> So I think we can say that this is rare, and its use can be agreed by other
> means between the users. Still it is a clearly defined case.
>
> 4. Audio from signing person related to sign language. This is more vague
> than the others.  It may be a person signing in video and adding spoken
> words in audio to signing, but influenced by the word order and grammar of
> sign language with some ambition to make it reasonably understandable for
> both deaf and hearing participants. There are even some spoken words
> created from sign language that are commonly used by hearing persons in
> such situations. But for that case I anyway think it is better to define
> the audio part as the spoken language it is derived from, because of its
> intention to be understandable for hearing persons. All other variants I
> can imagine are even closer to the spoken language and should be specified
> with spoken language tag. If we only want to have the audio stream
> established to hear the background in the signing situation, then we should
> not specify language use of the audio stream.
> Even if we know what sign language tag in audio stream would be, it may be
> just as good to leave it undefined.
> ------------------------------------------------------------
> ------------------------------------------------------------
> ------------------------
> So, new proposal:
>
> representation of sign language or fingerspelling in the text media stream.
> The use of such representation is rare and usually conveniently agreed by
> other means between the users during an established session. Common support
> of this indication SHOULD NOT be assumed or required.
>
> attribute for an audio stream SHOULD NOT be indicated and MAY be ignored on
> reception. Any use of spoken words or spoken language in the audio stream
> SHOULD, when it can be of importance for language communication, be
> indicated by the corresponding Language-Tag for spoken language in a

---

From: Randall Gellens <[email-masked]>
Date: Wed, 15 Feb 2017 16:26:45 -0800

At 3:52 PM -0800 2/15/17, Bernard Aboba wrote:

>  Gunnar Hellstrom said:
>
>  "The SDP Lang attribute in RFC 4566, where you 
> (Randall) say it is intended for specifying a 
> set of languages that all must be used in a 
> session, while I say that it is intended for 
> negotiation of at least one initial language."
>
>  [BA] At IETF 96 in Berlin, we had a discussion 
> of the history of the SDP Lang attribute within 
> the MMUSIC WG.
>
>  The Lang attribute was originally specified in 
> RFC 2327, which was published in April 1998, 
> more than four years prior to the publication 
> of Offer/Answer RFC 3264 (June 2002), and three 
> years prior to publication of the initial 
> draft-rosenberg-mmusic-sdp-offer-answer-00 
> (April 26, 2001).
>
>  As a result, the Lang attribute could not have 
> been designed for use in Offer/Answer 
> negotiation, but instead was intended for use 
> in the declarative SDP of multicast 
> conferencing.  Note that the Lang attribute was 
> not mentioned in RFC 3264, and noone at the 
> MMUSIC WG session was aware of a subsequent SIP 
> Offer/Answer implementation of it.

Which is what I was saying: it is descriptive of 
the media, which is very different from 
negotiation.  However, this is all moot now.

>  On Wed, Feb 15, 2017 at 1:41 AM, Gunnar 
> Hellström 
> <<mailto:[email-masked]>[email-masked]> 
> wrote:
>
> non-signed language tags with video.  My 
> proposal is that we say offerer SHOULD NOT send 
> such combinations and answerer MAY ignore 
> language. This allows future specifications for 
> the underlying uses Gunnar wants (such as 
> real-time subtitles in video and signed 
> equivalents in text).  Such future 
> specifications could define a use for the 
> language and media combinations and remove the 
> SHOULD NOT send and MAY ignore, or could define 
> a new mechanism.  I don't think we know enough 
> now to dictate what the solution should be.
>
>  <tel:%2B46%20708%20204%20288>+46 708 204 288
>

-------------- Randomly selected tag: ---------------
Computers are not intelligent.  They only think they are.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 22 Feb 2017 14:33:24 -0800

At 12:30 PM -0500 2/15/17, Paul Kyzivat wrote:

>  The mux-category is a big deal. There is a document in progress 
> that defines the mux-category for all existing attributes. 
> Attributes defined after that need to define their mux-category. 
> There is potentially a problem with attributes defined while this 
> work is in progress. That document for old attributes isn't going 
> to chase after ones defined concurrently. I think you will find 
> that if you don't define this then it will be caught and requested 
> either by a sdp-directorate review, or else the iesg review. So 
> just do it!

After reading through draft-ietf-mmusic-sdp-mux-attributes, I agree 
and have added "MUX Category:  normal" to both attributes.

> Until/unless that is defined there is no need to define dcsa for 
> this attribute.
>
>  	Thanks,
>  	Paul
>
>

-------------- Randomly selected tag: ---------------
Children are natural mimics who act like their parents despite every
effort to teach them good manners.

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 24 Feb 2017 09:06:49 +0100

> and have added "MUX Category:  normal" to both attributes.
NORMAL    with capitals seems to be the form to register.  please change 
in the draft.

Regards
Gunnar

--

---

From: Randall Gellens <[email-masked]>
Date: Fri, 24 Feb 2017 08:18:08 -0800

At 9:06 AM +0100 2/24/17, Gunnar Hellström wrote:

>>  After reading through 
>> draft-ietf-mmusic-sdp-mux-attributes, I agree 
>  NORMAL    with capitals seems to be the form to 
> register.  please change in the draft.

OK

-------------- Randomly selected tag: ---------------
[P]olitics, as a practice, whatever its professions, has always been
the systematic organization of hatreds.
                                    --American historian Henry Adams