Subject: [Slim] Change proposals for draft-ietf-slim-negotiating-human-language-00.txt

From: Gunnar Hellström <[email-masked]>
Date: Wed, 16 Mar 2016 07:36:32 +0100

In addition to the changes proposed in 
draft-ietf-slim-negotiating-human-language-00 for the preference 
regardless of media recently submitted, I have the following proposals 
for changes:

1. Change the first paragraph of section 5 from:
--------------------------------------------------------------------------------------------------

  RFC 4566 <https://tools.ietf.org/html/rfc4566>  specifies an attribute 'lang' which sounds similar to what
    is needed here, the difference being that it specifies that 'a=lang'
    is declarative with the semantics of multiple 'lang' attributes being
    that all of them are used, while we want a means to negotiate which
    one is used in each stream.  This difference means that the existing
    'lang' attribute can't be used and we need to define a new attribute.
-------------------------------------------------------------------------------

to
---------------------------------------------------------------------------------------

  RFC 4566 <https://tools.ietf.org/html/rfc4566>  specifies an attribute 'lang' which sounds similar to what
    is needed here. It specifies that 'a=lang'
    is declarative with the semantics of multiple 'lang' attributes being
    possible, indicating a number of possible languages in the session in
    an order of preference. Each party declares their capabilities and the
    language(s) used in the session can then be selected from the common set.
    We have however a need to specify direction of use of each language,
    and an order of preference between languages in different modalities.
    This difference means that the existing 'lang' attribute is not sufficient
    for our use and we need to complement it with definition of a new attribute.
--------------------------------------------------------------------------------------------------

2. change the last two paragraphs of section 5 from:
--------------------------------------------------------------------------------------------------------

  A recent search of RFCs and Internet Drafts turned up only one use of
    the 'lang' attribute (in a now-expired draft), and that sole use was
    coincidentally in exactly the way we need (erroniously assuming that
    the attribute was used for negotiation).  The sole use was in an
    example in a draft not directly related to language, where the
    initial invitation contains two 'a=lang' entries for a media stream
    (for English and Italian) and the OK accepts one of them (Italian).

    The example serves as evidence of the need for an SDP attribute with
    the semantics as described in this document; unfortunately, the
    existing 'lang' attribute is not it.
----------------------------------------------------------------------
to
-----------------------------------------------------------------------------
  A recent search of RFCs and Internet Drafts turned up only one use of
    the 'lang' attribute (in a now-expired draft), and that sole use was
    coincidentally in exactly the way we need.  The sole use was in an
    example in a draft not directly related to language, where the
    initial invitation contains two 'a=lang' entries for a media stream
    (for English and Italian) and the OK accepts one of them (Italian).

    This use was questioned in a discussion of that draft because of this
    sentence in RFC 4566: "Multiple lang attributes can be
       provided either at session or media level if the session
       description or media use multiple languages."
    An interpretation was that all declared languages must be used in
    the session, while the example showed use of a selection of the
    originally indicated languages. The uncertainty caused withdrawal
    of the example because it was not essential for the draft.

   However, studying the wording in RFC 4566 further, it is evident
   that a negotiation of languages was intended for the real-time case.
   When sdp is used to declare contents of a recorded session, then it
   makes sense to list the provided languages, while for a real-time
   session, it is obvious that the capabilities of the parties and the
   development of the session influence the selection of language for
   the session.
   The continuation in RFC 4566 "the order of the attributes indicates
   the order of importance of the various languages" makes it very clear
   that the list shall be seen as a list for selection and negotiation.
   The "order of importance" has no meaning if all languages must be provided.

   The conclusion is that the 'lang' attribute can be used for negotiation
   of one or more common languages to select from for use in a real-time session.
   A clarification is prepared for a possible future revision of RFC 4566.

   Thus, the 'lang' attribute satisfies our needs in many cases.

   Unfortunately, there are cases, where the users need to use different
   modalities in different directions, and when it is important to combine
   languages in different modalities. The 'lang' attribute does not have
   the details needed to cover these cases."
-------------------------------------------------------------------------------------------------

3. Change section 6 from:
-------------------------------------------------------
6 Proposed Solution

    An SDP attribute seems the natural choice to negotiate human
    (natural) language of an interactive media stream.  The attribute
    value should be a language tag perRFC 5646 <https://tools.ietf.org/html/rfc5646>  [RFC5646 <https://tools.ietf.org/html/rfc5646>] "
------------------------------------------------------------------
to
-----------------------------------------------------------------------
6 Proposed Solution
    An SDP attribute seems the natural choice to negotiate human
    (natural) language of an interactive media stream.  The attribute
    value should be a language tag perRFC 5646 <https://tools.ietf.org/html/rfc5646>  [RFC5646 <https://tools.ietf.org/html/rfc5646>]
    The new attribute can appear together with the existing 'lang'
    attribute to compose the preferred language/modality combinations
    offered or negotiated.
----------------------------------------------------------------------

Regards

Gunnar

Den 2015-11-02 kl. 17:09, skrev [email-masked]:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Selection of Language for Internet Media Working Group of the IETF.
>
>          Title           : Negotiating Human Language in Real-Time Communications
>          Author          : Randall Gellens
> 	Filename        : draft-ietf-slim-negotiating-human-language-00.txt
> 	Pages           : 18
> 	Date            : 2015-11-02
>
> Abstract:
>     Users have various human (natural) language needs, abilities, and
>     preferences regarding spoken, written, and signed languages.  When
>     establishing interactive communication ("calls") there needs to be a
>     way to negotiate (communicate and match) the caller's language and
>     media needs with the capabilities of the called party.  This is
>     especially important with emergency calls, where a call can be
>     handled by a call taker capable of communicating with the user, or a
>     translator or relay operator can be bridged into the call during
>     setup, but this applies to non-emergency calls as well (as an
>     example, when calling a company call center).
>
>     This document describes the need and a solution using new SDP stream
>     attributes.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 20 Mar 2016 09:35:01 +0100

Randall and all,

Did you accept the change proposal in the previous mail on this subject?
It reverts the reasoning in section 5 about the current sdp 'lang' 
attribute in RFC4566.

It is not logical to say that the 'lang' attribute describes a series of 
languages that all must be used in the session.
One clear evidence that it is meant for selection by negotiation is that 
RFC4566 says that multiple 'lang' attributes is a list in order of 
importance.
If all were required to be used, the order of importance has no 
relevance on SDP level.

The main conclusion is then that the current 'lang' attribute is usable 
for all simple cases in conversational sessions with symmetric use of 
the same language/modality in both directions and with only one medium 
specified for language use.

(It is less clear what is meant if the 'lang' attribute is used for more 
than one medium or on session level and one or more media.
Is it a promise from the offering part to provide simultaneous 
interpretation or an offer to select one alternative.
So that would need a clarification for the 'lang' attribute as well as 
for the 'humintlang-' attributes.)

Regards
Gunnar

Den 2016-03-16 kl. 07:36, skrev Gunnar Hellström:
>> Internet-Draft directories:http://www.ietf.org/shadow.html
>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> -- 
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Randall Gellens <[email-masked]>
Date: Sun, 20 Mar 2016 17:32:21 -0700

Hi Gunnar,

Thanks very much for your comments.  Please see in-line:

At 7:36 AM +0100 3/16/16, Gunnar Hellström wrote:

> draft-ietf-slim-negotiating-human-language-00 
> for the preference regardless of media recently 
> submitted, I have the following proposals for 
> changes:
>
>   <https://tools.ietf.org/html/rfc4566>RFC 4566 
> specifies an attribute 'lang' which sounds 
> similar to what
>   <https://tools.ietf.org/html/rfc4566>RFC 4566 
> specifies an attribute 'lang' which sounds 
> similar to what

I disagree.  I've reread the text in the draft 
and in RFC 4566 multiple times.  However, I added 
clarifying wording to the draft.

>  2. change the last two paragraphs of section 5 from:

While I disagree with your interpretation, I 
don't think it's needed to go into this level of 
detail at this point in the draft, so I left it 
unchanged.

>     value should be a language tag per 
> <https://tools.ietf.org/html/rfc5646>RFC 5646 
> [<https://tools.ietf.org/html/rfc5646>RFC5646] "
>     value should be a language tag per 
> <https://tools.ietf.org/html/rfc5646>RFC 5646 
> [<https://tools.ietf.org/html/rfc5646>RFC5646]

I don't think we have consensus on doing this, so I left it unchanged.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Citizens for corrupt government, unclean water, higher taxes,
unsafe streets, and poor schools.

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 21 Mar 2016 07:19:35 +0100

Randall,

I think it is unfair to RFC 4566 and RFC 3264 that we force an 
interpretation of the use of the 'lang' attribute on them that we do not 
agree on.

If we do not come to an agreement, we could instead just refrain from 
documenting an interpretation of how the 'lang' attribute works and  
conclude with

"Unfortunately, there are cases, where the users need to use different
    modalities in different directions, and when it is important to combine
    languages in different modalities. The 'lang' attribute does not have
    the details needed to cover these cases."

We must also make sure that we do not make the same kind of 
unders-pecification as apparently has been done in RFC 4566.
We need to describe what it means if we have language indications for 
the same direction in two (or more) media.
Shall it be understood as an indication that
     1) I am prepared to use both in the session or that
     2) I require both to be used or that
     3) I am not prepared to use both but offer them for selection.
If the normal interpretation is that it is for selection of one, how is 
the preference for one or the other indicated?
And if the normal interpretation is for a selection, how do we then 
indicate the case when we really strongly prefer to get both. ( e.g. 
voice plus captions ).

We also need to describe how use of both 'lang' and 'humintlang-' 
attributes in the same sdp shall be interpreted.

Regards

Gunnar

Den 2016-03-21 kl. 01:32, skrev Randall Gellens:
>> regardless of media recently submitted, I have the following 
>> proposals for changes:
>>
>>   <https://tools.ietf.org/html/rfc4566>RFC 4566 specifies an 
>> attribute 'lang' which sounds similar to what
>>   <https://tools.ietf.org/html/rfc4566>RFC 4566 specifies an 
>> attribute 'lang' which sounds similar to what
> I disagree.  I've reread the text in the draft and in RFC 4566 
> multiple times.  However, I added clarifying wording to the draft.
>
>>
> While I disagree with your interpretation, I don't think it's needed 
> to go into this level of detail at this point in the draft, so I left 
> it unchanged.
>
>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Mar 2016 10:37:07 -0400

In case you don't know, there is an rfc4566bis in progress.

If there is a problem with the precision of the definition of a=lang, it 
is possible to get it refined in 4566bis. However this will be 
constrained by backward compatibility issues. So it can probably be 
*clarified* as long as there isn't a lot of disagreement about what it 
means.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Mon, 21 Mar 2016 09:53:49 -0700

Hi Gunnar,

I do not believe we are forcing an interpretation 
on RFC 4566, rather, the drafts says, in an 
explanatory aside in parentheses, how the authors 
interpret it.  This is quite far from a normative 
statement.

I have re-read the text on language 
directionality within a media stream, and I do 
not see that we have an interoperability problem. 
It's possible that multiple streams with a 
language in the same direction are established, 
and it's possible that not all of them are 
actually used (e.g., if higher priority streams 
are established, perhaps the lower priority ones 
are not used).  I don't see that as causing an 
interoperability problem.

I could add a statement that both 'lang' and 
'humintlang-' attributes should not be used in 
the same stream, due to potential confusion.

At 7:19 AM +0100 3/21/16, Gunnar Hellström wrote:

>  Randall,
>
>  I think it is unfair to RFC 4566 and RFC 3264 
> that we force an interpretation of the use of 
> the 'lang' attribute on them that we do not 
> agree on.
>
>  If we do not come to an agreement, we could 
> instead just refrain from documenting an 
> interpretation of how the 'lang' attribute 
> works and  conclude with
>
>  We must also make sure that we do not make the 
> same kind of unders-pecification as apparently 
> has been done in RFC 4566.
>  We need to describe what it means if we have 
> language indications for the same direction in 
> two (or more) media.
>  If the normal interpretation is that it is for 
> selection of one, how is the preference for one 
> or the other indicated?
>  And if the normal interpretation is for a 
> selection, how do we then indicate the case 
> when we really strongly prefer to get both. ( 
> e.g. voice plus captions ).
>
>  We also need to describe how use of both 'lang' 
> and 'humintlang-' attributes in the same sdp 
> shall be interpreted.
>
>  Regards
>
>  Gunnar
>
>
>>> for the preference regardless of media 
>>> recently submitted, I have the following 
>>> proposals for changes:
>>>
>>>    <https://tools.ietf.org/html/rfc4566>RFC 
>>> 4566 specifies an attribute 'lang' which 
>>> sounds similar to what
>>>    <https://tools.ietf.org/html/rfc4566>RFC 
>>> 4566 specifies an attribute 'lang' which 
>>> sounds similar to what
>> and in RFC 4566 multiple times.  However, I 
>> added clarifying wording to the draft.
>>
>>>
>> don't think it's needed to go into this level 
>> of detail at this point in the draft, so I 
>> left it unchanged.
>>
>>>
>>> "

-------------- Randomly selected tag: ---------------
It is much easier to suggest solutions
when you know nothing about the problem.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 21 Mar 2016 09:55:50 -0700

Hi Paul,

It would probably be a good idea to add 
clarification on the use of 'lang' for a media. 
Depending on timing, it may be possible to 
clarify 'lang' with respect to 'humintlang' so 
that there is no confusion.

At 10:37 AM -0400 3/21/16, Paul Kyzivat wrote:

>  If there is a problem with the precision of the 
> definition of a=lang, it is possible to get it 
> refined in 4566bis. However this will be 
> constrained by backward compatibility issues. 
> So it can probably be *clarified* as long as 
> there isn't a lot of disagreement about what it 
> means.
>
>  	Thanks,
>  	Paul
>

-------------- Randomly selected tag: ---------------
The fact that a believer is happier than a skeptic is no more to the
point than the fact that a drunken man is happier than a sober one.
    --George Bernard Shaw

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Mar 2016 13:10:44 -0400

On 3/21/16 12:55 PM, Randall Gellens wrote:
> Hi Paul,
>
> It would probably be a good idea to add clarification on the use of
> 'lang' for a media. Depending on timing, it may be possible to clarify
> 'lang' with respect to 'humintlang' so that there is no confusion.

It isn't clear to me when work on 4566bis will wrapup. It has been going 
on for several years now. (But it *seems* to be coming to an end.)

It might be hard for it to reference humintlang without incorporating 
the definition into the bis. But it should certainly be possible to 
circumscribe the scope of 'lang' and indicate that some other attribute 
might be defined for another scope.

	Thanks,
	Paul

>>  If there is a problem with the precision of the definition of a=lang,
>> it is possible to get it refined in 4566bis. However this will be

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 21 Mar 2016 20:42:24 +0100

Den 2016-03-21 kl. 18:10, skrev Paul Kyzivat:
> It isn't clear to me when work on 4566bis will wrapup. It has been 
> going on for several years now. (But it *seems* to be coming to an end.)
>
> circumscribe the scope of 'lang' and indicate that some other 
> attribute might be defined for another scope.
I have communicated in the mmusic list and indicated the need to clarify 
the use of 'lang' in 4566bis.
I think it was in November or December. A wording was accepted that 
makes it clear that multiple languages means a selection and an answer 
can select what to use.
But I am afraid that I only discussed the issue of all or selection, and 
not what we discussed today, about the need to indicate preferences 
between languages in different media and the need to specify what it 
means to have languages in multiple media. ( is it for selection or a 
required combination )

Gunnar
>>>>>>      for our use and we need to complement it with definition of 
>>>>>> a new
>>>>>>  attribute.
>>>>>>
>>>>>>
>>>>>>      This use was questioned in a discussion of that draft 
>>>>>> because of
>>>>>>  this
>>>>>>     The "order of importance" has no meaning if all languages 
>>>>>> must be
>>>>>>  provided.
>>>>>>
>>>>>>     A clarification is prepared for a possible future revision of 
>>>>>> RFC
>>>>>>  4566.
>>>>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 21 Mar 2016 21:47:53 +0100

Hi Randall,
Den 2016-03-21 kl. 17:53, skrev Randall Gellens:
> Hi Gunnar,
>
> I do not believe we are forcing an interpretation on RFC 4566, rather, 
> the drafts says, in an explanatory aside in parentheses, how the 
> authors interpret it.  This is quite far from a normative statement.
It will be documented anyway, and just as you looked at the discussion 
around the STOX - example and got influenced by it, there is a risk that 
we spread more uncertainty in the topic or lead others to make unlogical 
conclusions.
Let it be sufficient to say that 'lang' does not have the detailing we need.
>
>
> I have re-read the text on language directionality within a media 
> stream, and I do not see that we have an interoperability problem. 
> It's possible that multiple streams with a language in the same 
> direction are established, and it's possible that not all of them are 
> actually used (e.g., if higher priority streams are established, 
> perhaps the lower priority ones are not used).  I don't see that as 
> causing an interoperability problem.
See use cases 2.3, 2.4, 2.5 and 2.6 in the use-case document just 
published by Natasha. Thanks!
Only 2.3 is solved by the current specification. The other needs 
cross-media preferences.
They could need media and language grouping as well, but I prefer that 
we try to solve that with a rule saying that languages in different 
media specified on the same preference level shall be seen as a group 
that is required together, while languages in different media specified 
with different preference levels specify single languages provided for 
selection.

Note also that the primary function of these attributes are not to guide 
which media streams shall be accepted and activated, it is usually good 
with media streams even if they are not used for language.
The function I see as the main purpose is to make sure that the caller 
gets in contact with a person with the right language competence and if 
needed a suitable relay service is invoked in the call in order to cover 
any gaps in language coverage.
Of course a media stream must not be excluded that is needed for the 
selected language combination.  But the opposite should not happen - 
that a media stream is ignored because it is not needed for language 
communication.

>
>
> I could add a statement that both 'lang' and 'humintlang-' attributes 
> should not be used in the same stream, due to potential confusion.
Yes, if we cannot agree on how to interpret 'lang', it would be a solution.
But the problem is also between media. 'lang' in one medium and 
'humintlang' in another is also undefined if it represents an offered 
selection, or a required combination and if selection, what preference 
levels do they represent?
We must then also think about the conflict between 'lang' on session 
level and 'humintlang' on media level.

/Gunnar
>> interpretation of the use of the 'lang' attribute on them that we do 
>> not agree on.
>>
>>  If we do not come to an agreement, we could instead just refrain 
>> from documenting an interpretation of how the 'lang' attribute works 
>> and  conclude with
>>
>>  We need to describe what it means if we have language indications 
>> for the same direction in two (or more) media.
>>  If the normal interpretation is that it is for selection of one, how 
>> is the preference for one or the other indicated?
>>>> RFC 4566.
>>>  While I disagree with your interpretation, I don't think it's 
>>> needed to go into this level of detail at this point in the draft, 
>>> so I left it unchanged.
>>>
>>>>

---

From: Natasha Rooney <[email-masked]>
Date: Thu, 31 Mar 2016 16:39:56 +0000

Hi all,

It’s about time (or, perhaps late by two weeks!) that we decide on our agenda for next week’s meeting. We have an hour between 16:20-17:20 on Thursday and we will have both remote and present attendees.

In this meeting we will be discussing the below open issue and updates that have been made / will be made to the existing documents. The meeting should be less than an hour. A guidelines agenda is:

Welcome
Update on SLIM new and existing docs
draft-ietf-slim-multilangcontent-00
draft-ietf-slim-negotiating-human-language-01
draft-ietf-slim-use-cases-00
Open Issue(s)

If you have something else to add please do let me know as soon as you can so I can add this to the agenda. I will publish this tomorrow.

Also, please let me know if you are attending in person or not if you haven’t already!

Thanks all!

Natasha

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

On Mar 21, 2016, at 8:47 PM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

Hi Randall,

I do not believe we are forcing an interpretation on RFC 4566, rather, the drafts says, in an explanatory aside in parentheses, how the authors interpret it.  This is quite far from a normative statement.
It will be documented anyway, and just as you looked at the discussion around the STOX - example and got influenced by it, there is a risk that we spread more uncertainty in the topic or lead others to make unlogical conclusions.
Let it be sufficient to say that 'lang' does not have the detailing we need.

I have re-read the text on language directionality within a media stream, and I do not see that we have an interoperability problem. It's possible that multiple streams with a language in the same direction are established, and it's possible that not all of them are actually used (e.g., if higher priority streams are established, perhaps the lower priority ones are not used).  I don't see that as causing an interoperability problem.
See use cases 2.3, 2.4, 2.5 and 2.6 in the use-case document just published by Natasha. Thanks!
Only 2.3 is solved by the current specification. The other needs cross-media preferences.
They could need media and language grouping as well, but I prefer that we try to solve that with a rule saying that languages in different media specified on the same preference level shall be seen as a group that is required together, while languages in different media specified with different preference levels specify single languages provided for selection.

Note also that the primary function of these attributes are not to guide which media streams shall be accepted and activated, it is usually good with media streams even if they are not used for language.
The function I see as the main purpose is to make sure that the caller gets in contact with a person with the right language competence and if needed a suitable relay service is invoked in the call in order to cover any gaps in language coverage.
Of course a media stream must not be excluded that is needed for the selected language combination.  But the opposite should not happen - that a media stream is ignored because it is not needed for language communication.

I could add a statement that both 'lang' and 'humintlang-' attributes should not be used in the same stream, due to potential confusion.
Yes, if we cannot agree on how to interpret 'lang', it would be a solution.
But the problem is also between media. 'lang' in one medium and 'humintlang' in another is also undefined if it represents an offered selection, or a required combination and if selection, what preference levels do they represent?
We must then also think about the conflict between 'lang' on session level and 'humintlang' on media level.

/Gunnar

Randall,

I think it is unfair to RFC 4566 and RFC 3264 that we force an interpretation of the use of the 'lang' attribute on them that we do not agree on.

If we do not come to an agreement, we could instead just refrain from documenting an interpretation of how the 'lang' attribute works and  conclude with

We must also make sure that we do not make the same kind of unders-pecification as apparently has been done in RFC 4566.
We need to describe what it means if we have language indications for the same direction in two (or more) media.
Shall it be understood as an indication that
    1) I am prepared to use both in the session or that
    2) I require both to be used or that
    3) I am not prepared to use both but offer them for selection.
If the normal interpretation is that it is for selection of one, how is the preference for one or the other indicated?
And if the normal interpretation is for a selection, how do we then indicate the case when we really strongly prefer to get both. ( e.g. voice plus captions ).

We also need to describe how use of both 'lang' and 'humintlang-' attributes in the same sdp shall be interpreted.

Regards

Gunnar

 In addition to the changes proposed in draft-ietf-slim-negotiating-human-language-00 for the preference regardless of media recently submitted, I have the following proposals for changes:

  <https://tools.ietf.org/html/rfc4566>RFC 4566 specifies an attribute 'lang' which sounds similar to what

 to

  <https://tools.ietf.org/html/rfc4566>RFC 4566 specifies an attribute 'lang' which sounds similar to what

I disagree.  I've reread the text in the draft and in RFC 4566 multiple times.  However, I added clarifying wording to the draft.

While I disagree with your interpretation, I don't think it's needed to go into this level of detail at this point in the draft, so I left it unchanged.

    value should be a language tag per <https://tools.ietf.org/html/rfc5646>RFC 5646 [<https://tools.ietf.org/html/rfc5646>RFC5646] "
    value should be a language tag per <https://tools.ietf.org/html/rfc5646>RFC 5646 [<https://tools.ietf.org/html/rfc5646>RFC5646]

--
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288

_______________________________________________
SLIM mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/slim

--
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.