Subject: [Slim] IETF95, Use Cases doc, and others

From: Natasha Rooney <[email-masked]>
Date: Wed, 2 Mar 2016 16:37:40 +0000

Hi all!

We are 1 month and 1 day away from the start of IETF95! Gasp! We have some work to get on with before IETF95, where we will have a very short (and hopefully fruitful meeting!) discussing the last issues we have remaining.

The IETF95 link is below for those of you who still need to book hotels:
https://ietf.org/meeting/95/index.html

I am going to be working on finishing the use cases document from now until IETF95. Please submit any issues or pull requests to the github repo or tell me directly:
https://github.com/ietf-slim-wg/slim-use-cases/

With our other two documents I believe the modality issues is still at large. Can someone catch me up on the last discussions here? I remember that we were still discussing it and no decisions had been made - is this correct? On discussions with other IETF attendees many said that dual modality - whilst supported by use cases - is awfully difficult to implement, is this the same as the thoughts within this group?
https://datatracker.ietf.org/wg/slim/documents/

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

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.

---

From: Natasha Rooney <[email-masked]>
Date: Fri, 11 Mar 2016 16:28:27 +0000

Hi all!

IETF95 Deadline
Just a quick reminder that the IETF95 document submission deadline is coming up fast (March 21st). I am going to submit the use cases draft before then with the use cases I have collected from the last meeting. If you want to see what we have so far then see the link below (excuse the xml):
https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml

Our Document Status
With regards to our two other documents, I believe the only issue we have is regarding the dual modality use case, and the difficulty of dealing with this within real-time communications (this obviously only applies to draft-ietf-slim-negotiating-human-language-00). My question to you all is: do you have any other outstanding issues with either draft? If not, we should be in a state to clean them up and publish.

Bernard and I are having a chairs chat next week so we can discuss plans for IETF95 and the document status, so please let us know before the end of Tuesday next week as to whether you have any issues you wish to raise.

Thanks everyone!

Natasha

On Mar 2, 2016, at 4:37 PM, Natasha Rooney <[email-masked]<mailto:[email-masked]>> wrote:

Hi all!

Thanks all!

Natasha

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

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 12 Mar 2016 10:41:56 +0100

Natasha and all,

The use case collection looks good.
The reasoning about implementability need a description about what 
version of the negotiating-human-language draft it refers to.  We hope 
to improve, so we get "possible" on nearly all cases.

It is time to act on the conclusions of the use cases.

My suggestion:
Add in the negotiating-human-language draft the following:

1. A coding for absolute level of preference for a modality-language 
combination in three levels: preferred, can-do, last-resort. Shall we 
explicit using words, or cryptic, using * and other special characters?

2. A clear interpreting rule, saying that for needs of two modalities, 
one in each direction, the directional attributes together with absolute 
coding of preference shall be used, including some default rule for when 
no absolute coding is provided.

3. A description of offer-answer handling rules, making it very clear if 
the attributes in the answer indicate capabilities and preferences from 
the point of view of the party sending the SDP, or from the point of 
view of the offering party.
The first case would mean that "I want to talk English" and "I want to 
read English text"  shall be answered with "I want to listen to spoken 
English" and "I will type English" to get a match ,    The second case 
would mean that "I want to talk English" and "I want to read English 
text" would be answered with "I accept that you talk English" and "I 
accept that you will read English text" thus sending attributes as if 
coded from the offering party to get a match.
The first case is more evident for the user, while the second case is 
easier to parse and check for a match.

4. A conclusion that need for speech-to-speech relay services is out of 
scope and need to be solved by other indications. Do anyone have ideas 
for such indications? Call-Info with purpose and URI to a suitable 
service? Make a REFER to bring in the service? Call with a URI-list? ( 
Yes, it is out of scope, but I am interested to have an agreed best 
practice solutions for it.)

  Regards

Gunnar

Den 2016-03-11 kl. 17:28, skrev Natasha Rooney:
> Hi all!
>
> *IETF95 Deadline*
> Just a quick reminder that the IETF95 document submission deadline is 
> coming up fast (*March 21st*). I am going to submit the use cases 
> draft before then with the use cases I have collected from the last 
> meeting. If you want to see what we have so far then see the link 
> below (excuse the xml):
> *Our Document Status*
> With regards to our two other documents, I believe the only issue we 
> have is regarding the dual modality use case, and the difficulty of 
> dealing with this within real-time communications (this obviously only 
> applies to draft-ietf-slim-negotiating-human-language-00). My question 
> to you all is: *do you have any other outstanding issues with either 
> draft? *If not, we should be in a state to clean them up and publish.
>
> Bernard and I are having a chairs chat next week so we can discuss 
> plans for IETF95 and the document status, so please *let us know 
> before the end of Tuesday next week as to whether you have any issues 
> you wish to raise*.
>
> Thanks everyone!
>
> 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]>
>
>
>> We are 1 month and 1 day away from the start of IETF95! Gasp! We have 
>> some work to get on with before IETF95, where we will have a very 
>> short (and hopefully fruitful meeting!) discussing the last issues we 
>> have remaining.
>>
>> I am going to be working on finishing the use cases document from now 
>> until IETF95. Please submit any issues or pull requests to the github 
>> repo or tell me directly:
>> With our other two documents I believe the modality issues is still 
>> at large. Can someone catch me up on the last discussions here? I 
>> remember that we were still discussing it and no decisions had been 
>> made - is this correct? On discussions with other IETF attendees many 
>> said that dual modality - whilst supported by use cases - is awfully 
>> difficult to implement, is this the same as the thoughts within this 
>> group?
>> 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]>
>>
>>
>> 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.
>>
>> [email-masked] <mailto:[email-masked]>
> 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.
>
>
>
> [email-masked]

---

From: Randall Gellens <[email-masked]>
Date: Sat, 12 Mar 2016 14:53:27 -0800

Hi Gunnar and everyone,

In the interest of keeping the draft as simple as 
possible for the initial version, I do not think 
we need to add the absolute level of preference 
that you suggest.

At 10:41 AM +0100 3/12/16, Gunnar Hellström wrote:

>  The reasoning about implementability need a 
> description about what version of the 
> negotiating-human-language draft it refers to. 
> We hope to improve, so we get "possible" on 
> nearly all cases.
>
>  1. A coding for absolute level of preference 
> for a modality-language combination in three 
> levels: preferred, can-do, last-resort. Shall 
> we explicit using words, or cryptic, using * 
> and other special characters?
>
>  2. A clear interpreting rule, saying that for 
> needs of two modalities, one in each direction, 
> the directional attributes together with 
> absolute coding of preference shall be used, 
> including some default rule for when no 
> absolute coding is provided.
>
>  3. A description of offer-answer handling 
> rules, making it very clear if the attributes 
> in the answer indicate capabilities and 
> preferences from the point of view of the party 
> sending the SDP, or from the point of view of 
> the offering party.
>  The first case would mean that "I want to talk 
> English" and "I want to read English text" 
> shall be answered with "I want to listen to 
> spoken English" and "I will type English" to 
> get a match , The second case would mean that 
> "I want to talk English" and "I want to read 
> English text" would be answered with "I accept 
> that you talk English" and "I accept that you 
> will read English text" thus sending attributes 
> as if coded from the offering party to get a 
> match.
>  The first case is more evident for the user, 
> while the second case is easier to parse and 
> check for a match.
>
>  4. A conclusion that need for speech-to-speech 
> relay services is out of scope and need to be 
> solved by other indications. Do anyone have 
> ideas for such indications? Call-Info with 
> purpose and URI to a suitable service? Make a 
> REFER to bring in the service? Call with a 
> URI-list? ( Yes, it is out of scope, but I am 
> interested to have an agreed best practice 
> solutions for it.)
>
>  Regards
>
>  Gunnar
>
>
>>  Just a quick reminder that the IETF95 document 
>> submission deadline is coming up fast (March 
>> 21st). I am going to submit the use cases 
>> draft before then with the use cases I have 
>> collected from the last meeting. If you want 
>> to see what we have so far then see the link 
>> below (excuse the xml):
>> 
>> <https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml>https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml
>>
>>  Our Document Status
>>  With regards to our two other documents, I 
>> believe the only issue we have is regarding 
>> the dual modality use case, and the difficulty 
>> of dealing with this within real-time 
>> communications (this obviously only applies to 
>> draft-ietf-slim-negotiating-human-language-00). 
>> My question to you all is: do you have any 
>> other outstanding issues with either draft? If 
>> not, we should be in a state to clean them up 
>> and publish.
>>
>>  Bernard and I are having a chairs chat next 
>> week so we can discuss plans for IETF95 and 
>> the document status, so please let us know 
>> before the end of Tuesday next week as to 
>> whether you have any issues you wish to raise.
>>
>>  Thanks everyone!
>>
>>
>>  Natasha
>>
>>
>> <mailto:[email-masked]> [email-masked] | 
>> +44 (0) 7730 219 765 | @thisNatasha | Skype: 
>> <mailto:[email-masked]>[email-masked]
>>
>>
>>>  On Mar 2, 2016, at 4:37 PM, Natasha Rooney 
>>> <<mailto:[email-masked]>[email-masked]> 
>>> wrote:
>>>
>>>  Hi all!
>>>
>>>  We are 1 month and 1 day away from the start 
>>> of IETF95! Gasp! We have some work to get on 
>>> with before IETF95, where we will have a very 
>>> short (and hopefully fruitful meeting!) 
>>> discussing the last issues we have remaining.
>>>
>>> <https://ietf.org/meeting/95/index.html>https://ietf.org/meeting/95/index.html
>>>
>>>  I am going to be working on finishing the use 
>>> cases document from now until IETF95. Please 
>>> submit any issues or pull requests to the 
>>> github repo or tell me directly:
>>> 
>>> <https://github.com/ietf-slim-wg/slim-use-cases/>https://github.com/ietf-slim-wg/slim-use-cases/
>>>
>>>  With our other two documents I believe the 
>>> modality issues is still at large. Can 
>>> someone catch me up on the last discussions 
>>> here? I remember that we were still 
>>> discussing it and no decisions had been made 
>>> - is this correct? On discussions with other 
>>> IETF attendees many said that dual modality - 
>>> whilst supported by use cases - is awfully 
>>> difficult to implement, is this the same as 
>>> the thoughts within this group?
>>> 
>>> <https://datatracker.ietf.org/wg/slim/documents/>https://datatracker.ietf.org/wg/slim/documents/
>>>
>>>  Thanks all!
>>>
>>>  Natasha
>>>
>>> <mailto:[email-masked]> 
>>> <mailto:[email-masked]>[email-masked] | 
>>> +44 (0) 7730 219 765 | @thisNatasha | Skype: 
>>> <mailto:[email-masked]>[email-masked]
>>>
>>>
>>>  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.
>>>
>>>  <mailto:[email-masked]>[email-masked]
>>> 
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>  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.
>>
>>
>>
>>  <mailto:[email-masked]>[email-masked]
>> 
>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>
>
>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A great many people think they are thinking when they are really
rearranging their prejudices.
    --William James

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 13 Mar 2016 10:39:00 +0100

Randall,

Den 2016-03-12 kl. 23:53, skrev Randall Gellens:
> Hi Gunnar and everyone,
>
> In the interest of keeping the draft as simple as possible for the 
> initial version, I do not think we need to add the absolute level of 
> preference that you suggest.
And I think the draft will not be sufficiently usable without a 
mechanism to indicate absolute preference in a way so that the 
preference between languages and modalities in different media is indicated.
For example I prefer to talk and hear spoken English in audio, but can 
accept to type and read English text.
or another example:
I prefer to talk and hear spoken French in audio but can accept to sign 
and see French sign language in video.

Without a way to make the distinction, we give no clue to the other 
party on why language is indicated in more than one media. Are all 
desired or not?
And if you cannot indicate an option with lower preference then you may 
lose calls or get relay services invoked when they are not needed, 
wasting resources and making the calls less direct and less personal.

We could probably do with just two levels of preference: Preferred and 
possible.
While searching in 
https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00
for a possiblity to include that in the syntax without increasing 
complexity, I saw the Advisory vs Required indication by an asterisk in 
section 6.3.
I do not expect that indication to be of much value,  so I intended to 
propose to change its use to be a priority indicator. But it seems too 
tightly coupled to the use in language-matching in RFC 2616, so I 
abstain from proposing that and instead with hesitation propose that we 
include the q= factor notation from RFC 2616 for indicating preference.

I suggest a change in section 6.2:

-------------------------------------current text in 
6.2-------------------------------------------------

       a=humintlang-send:<language tag>
       a=humintlang-recv:<language tag>

    Each can appear multiple times in an offer for a media stream.

    In an offer, the 'humintlang-send' values constitute a list in
    preference order (first is most preferred) of the languages the
    offerer wishes to send using the media, and the 'humintlang-recv'
    values constitute a list in preference order of the languages the
    offerer wishes to receive using the media.

-------------------------------------proposed changed text in 
6.2----------------------------------

       a=humintlang-send:<language tag>[ ";" "q" "=" qvalue ]

       a=humintlang-recv:<language tag>[ ";" "q" "=" qvalue ]

    Each can appear multiple times in an offer for a media stream.

    In an offer the 'humintlang-send' values constitute a list of the languages the
    offerer wishes to send using the media, and the 'humintlang-recv'
    values constitute a list of the languages the
    offerer wishes to receive using the media.  The q-values represent a preference level
    for using the indicated language and modality relative to all other languages and
    modalities indicated for the same direction in the whole SDP.
    The quality value defaults to "q=1" and has the same syntax and usage rules as for 'Accept-Language' in RFC 2616 [RFC2616].

    If more than one language is specified for the same media and direction with the same q-value,
    they SHALL be listed in preference order.

---------------------------------End of change proposal.---------------------------------------------

>> explicit using words, or cryptic, using * and other special characters?
Changed to q-value above
>>
>>  2. A clear interpreting rule, saying that for needs of two 
>> modalities, one in each direction, the directional attributes 
>> together with absolute coding of preference shall be used, including 
>> some default rule for when no absolute coding is provided.
What is said for dual modalities in 6.2 just below the change proposal 
above may be sufficient.
>>
>>
>>  3. A description of offer-answer handling rules, making it very 
>> clear if the attributes in the answer indicate capabilities and 
>> preferences from the point of view of the party sending the SDP, or 
>> from the point of view of the offering party.
>>  The first case would mean that "I want to talk English" and "I want 
>> to read English text" shall be answered with "I want to listen to 
>> spoken English" and "I will type English" to get a match , The second 
>> case would mean that "I want to talk English" and "I want to read 
>> English text" would be answered with "I accept that you talk English" 
>> and "I accept that you will read English text" thus sending 
>> attributes as if coded from the offering party to get a match.
>>  The first case is more evident for the user, while the second case 
>> is easier to parse and check for a match.
In 6.2 we have the rule that both the offeror and the answering party 
indicate values from their own point of view. I think that is doable.
>>
>>  4. A conclusion that need for speech-to-speech relay services is out 
>> of scope and need to be solved by other indications. Do anyone have 
>> ideas for such indications? Call-Info with purpose and URI to a 
>> suitable service? Make a REFER to bring in the service? Call with a 
>> URI-list? ( Yes, it is out of scope, but I am interested to have an 
>> agreed best practice solutions for it.)
We take that separately and concentrate on the preference scope to cover 
all modalities here.

/Gunnar
>>>  Just a quick reminder that the IETF95 document submission deadline 
>>> is coming up fast (March 21st). I am going to submit the use cases 
>>>  With regards to our two other documents, I believe the only issue 
>>> we have is regarding the dual modality use case, and the difficulty 
>>> of dealing with this within real-time communications (this obviously 
>>> only applies to draft-ietf-slim-negotiating-human-language-00). My 
>>> question to you all is: do you have any other outstanding issues 
>>> with either draft? If not, we should be in a state to clean them up 
>>> and publish.
>>>
>>> plans for IETF95 and the document status, so please let us know 
>>> before the end of Tuesday next week as to whether you have any 
>>> issues you wish to raise.
>>>
>>>  Thanks everyone!
>>>
>>>
>>>  Natasha
>>>
>>>
>>>  Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA 
>>> | <mailto:[email-masked]> [email-masked] | +44 (0) 7730 219 765 
>>> | @thisNatasha | Skype: <mailto:[email-masked]>[email-masked]
>>>
>>>
>>>> <<mailto:[email-masked]>[email-masked]> wrote:
>>>>
>>>>  Hi all!
>>>>
>>>>  We are 1 month and 1 day away from the start of IETF95! Gasp! We 
>>>> have some work to get on with before IETF95, where we will have a 
>>>> very short (and hopefully fruitful meeting!) discussing the last 
>>>> issues we have remaining.
>>>>
>>>>  I am going to be working on finishing the use cases document from 
>>>> now until IETF95. Please submit any issues or pull requests to the 
>>>>  With our other two documents I believe the modality issues is 
>>>> still at large. Can someone catch me up on the last discussions 
>>>> here? I remember that we were still discussing it and no decisions 
>>>> had been made - is this correct? On discussions with other IETF 
>>>> attendees many said that dual modality - whilst supported by use 
>>>> cases - is awfully difficult to implement, is this the same as the 
>>>> thoughts within this group?
>>>>
>>>>  Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA 
>>>> | <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>[email-masked] | +44 (0) 7730 219 765 | 
>>>> @thisNatasha | Skype: <mailto:[email-masked]>[email-masked]
>>>>
>>>>
>>>>  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.
>>>>
>>>  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 

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

---

From: Randall Gellens <[email-masked]>
Date: Mon, 14 Mar 2016 18:15:29 -0700

Hi Gunnar,

I think adding q= factor is much more complexity 
than is needed, and I remain unconvinced that we 
must have a preference indication at the start. 
I don't see that use cases are impossible without 
it.  It seems to me that the only difference it 
makes is to skip establishing some requested 
media streams if others are established.  I 
suspect that in most cases, the ones that could 
be skipped would be the easier ones (without 
relay/interpretation services).  Having an extra 
text or audio stream that is not used is not a 
big deal.

If we keep the draft very simple to start with, 
then after we have some deployment experience, we 
can create a revision or an extension that adds 
the features that we found we need, in the way we 
found we need them.  In my experience, this is a 
better approach than trying to think of all 
aspects of the solution at the start, since doing 
so inevitably adds complexity and adds features 
in ways that turn out to not be ideal.

So, I would like to avoid adding preference now, 
but would be happy to work on an update or 
extension in the future if we find that we need 
it.

At 10:39 AM +0100 3/13/16, Gunnar Hellström wrote:

>>  In the interest of keeping the draft as simple 
>> as possible for the initial version, I do not 
>> think we need to add the absolute level of 
>  And I think the draft will not be sufficiently 
> usable without a mechanism to indicate absolute 
> preference in a way so that the preference 
> between languages and modalities in different 
> media is indicated.
>  For example I prefer to talk and hear spoken 
> English in audio, but can accept to type and 
> read English text.
>  or another example:
>  I prefer to talk and hear spoken French in 
> audio but can accept to sign and see French 
> sign language in video.
>
>  Without a way to make the distinction, we give 
> no clue to the other party on why language is 
> indicated in more than one media. Are all 
> desired or not?
>  And if you cannot indicate an option with lower 
> preference then you may lose calls or get relay 
> services invoked when they are not needed, 
>  We could probably do with just two levels of 
> preference: Preferred and possible.
>  While searching in 
>  for a possiblity to include that in the syntax 
> without increasing complexity, I saw the 
> Advisory vs Required indication by an asterisk 
> in section 6.3.
>  I do not expect that indication to be of much 
> value,  so I intended to propose to change its 
> use to be a priority indicator. But it seems 
> too tightly coupled to the use in 
> language-matching in RFC 2616, so I abstain 
> from proposing that and instead with hesitation 
> propose that we include the q= factor notation 
> from RFC 2616 for indicating preference.
>
> The q-values represent a preference level
>     for using the indicated language and 
> modality relative to all other languages and
>     The quality value defaults to "q=1" and has 
> the same syntax and usage rules as for 
> 'Accept-Language' in RFC 2616 [RFC2616].
>
>     If more than one language is specified for 
> the same media and direction with the same 
> q-value,
>  ---------------------------------End of change 
> proposal.---------------------------------------------
>
>
>     
>
>>
>>> negotiating-human-language draft it refers 
>>> to. We hope to improve, so we get "possible" 
>>> on nearly all cases.
>>>
>>>   2. A clear interpreting rule, saying that 
>>> for needs of two modalities, one in each 
>>> direction, the directional attributes 
>>> together with absolute coding of preference 
>>> shall be used, including some default rule 
>>> for when no absolute coding is provided.
>  What is said for dual modalities in 6.2 just 
> below the change proposal above may be 
> sufficient.
>>>
>>>
>>> preferences from the point of view of the 
>>> party sending the SDP, or from the point of 
>>>   The first case would mean that "I want to 
>>> talk English" and "I want to read English 
>>> text" shall be answered with "I want to 
>>> listen to spoken English" and "I will type 
>>> English" to get a match , The second case 
>>> would mean that "I want to talk English" and 
>>> "I want to read English text" would be 
>>> answered with "I accept that you talk 
>>> English" and "I accept that you will read 
>>> English text" thus sending attributes as if 
>  In 6.2 we have the rule that both the offeror 
> and the answering party indicate values from 
> their own point of view. I think that is doable.
>>>
>>>   4. A conclusion that need for 
>>> speech-to-speech relay services is out of 
>>> scope and need to be solved by other 
>>> indications. Do anyone have ideas for such 
>>> indications? Call-Info with purpose and URI 
>>> to a suitable service? Make a REFER to bring 
>>> in the service? Call with a URI-list? ( Yes, 
>>> it is out of scope, but I am interested to 
>>> have an agreed best practice solutions for 
>>> it.)
>  We take that separately and concentrate on the 
> preference scope to cover all modalities here.
>
>  /Gunnar
>>>
>>>   Regards
>>>
>>>   Gunnar
>>>
>>>
>>>>   Just a quick reminder that the IETF95 
>>>> document submission deadline is coming up 
>>>> fast (March 21st). I am going to submit the 
>>>> use cases draft before then with the use 
>>>> cases I have collected from the last 
>>>> meeting. If you want to see what we have so 
>>>> far then see the link below (excuse the xml):
>>>>
>>>> 
>>>> the dual modality use case, and the 
>>>> difficulty of dealing with this within 
>>>> real-time communications (this obviously 
>>>> only applies to 
>>>> other outstanding issues with either draft? 
>>>> If not, we should be in a state to clean 
>>>> them up and publish.
>>>>
>>>>>   We are 1 month and 1 day away from the 
>>>>> start of IETF95! Gasp! We have some work to 
>>>>> get on with before IETF95, where we will 
>>>>> have a very short (and hopefully fruitful 
>>>>> meeting!) discussing the last issues we 
>>>>> have remaining.
>>>>>
>>>>>   I am going to be working on finishing the 
>>>>> use cases document from now until IETF95. 
>>>>> Please submit any issues or pull requests 
>>>>> to the github repo or tell me directly:
>>>>>
>>>>> 
>>>>> discussing it and no decisions had been 
>>>>> made - is this correct? On discussions with 
>>>>> other IETF attendees many said that dual 
>>>>> modality - whilst supported by use cases - 
>>>>> is awfully difficult to implement, is this 
>>>>> the same as the thoughts within this group?
>>>>>
>>>>> 
>>>>>   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.
>>>>>

-------------- Randomly selected tag: ---------------
Democracy is a beautiful thing, except for that part about letting
just any old yokel vote. --Anonymous, Age 10

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 16 Mar 2016 00:20:41 +0100

Hi Randall,

Den 2016-03-15 kl. 02:15, skrev Randall Gellens:
> Hi Gunnar,
>
> I think adding q= factor is much more complexity than is needed, and I 
> remain unconvinced that we must have a preference indication at the 
> start. I don't see that use cases are impossible without it.  It seems 
> to me that the only difference it makes is to skip establishing some 
> requested media streams if others are established.  I suspect that in 
> most cases, the ones that could be skipped would be the easier ones 
> (without relay/interpretation services).  Having an extra text or 
> audio stream that is not used is not a big deal.
I agree that adding the q-factor was not what I originally thought of as 
the solution.  But since I realised that we could not reuse the * -mark 
of the less-needed indication of Advisory vs required for this purpose I 
thought it was best to reuse another already existing coding. You are 
welcome to propose another alternative.
Because we need a preference indication that is independent of media. I 
have called it "absolute preference", but that might not be the best 
words. It can be solved with a relative preference. The important thing 
is that it is about preference regardless of media
You have specified one preference order within each media, but that is 
not sufficient.
It is essential to be able to specify e.g. "I prefer to speak but can 
accept to type".
And to indicate what modality/language combination is your favourite 
among possible combinations.

And it is not primarily about establishing media streams, it is about 
connecting the right persons and services to the call and have an 
indication in what modality and language to handle the call.

With the long turn-around-times in IETF I absolutely do not want to wait 
one generation before we satisfy this need.

Can we accept the q-factor or invent something new, e.g.  "; hi" for the 
highest preferred ones.

I think we have reduced complexity a lot anyway so that this one could stay.

Regards,
Gunnar

>
> If we keep the draft very simple to start with, then after we have 
> some deployment experience, we can create a revision or an extension 
> that adds the features that we found we need, in the way we found we 
> need them.  In my experience, this is a better approach than trying to 
> think of all aspects of the solution at the start, since doing so 
> inevitably adds complexity and adds features in ways that turn out to 
> not be ideal.
>
> So, I would like to avoid adding preference now, but would be happy to 
> work on an update or extension in the future if we find that we need it.
>
>>  For example I prefer to talk and hear spoken English in audio, but 
>> can accept to type and read English text.
>>  or another example:
>>  I prefer to talk and hear spoken French in audio but can accept to 
>> sign and see French sign language in video.
>>
>>  And if you cannot indicate an option with lower preference then you 
>> may lose calls or get relay services invoked when they are not 
>> needed, wasting resources and making the calls less direct and less 
>> personal.
>>
>>  We could probably do with just two levels of preference: Preferred 
>> and possible.
>>  While searching in 
>> complexity, I saw the Advisory vs Required indication by an asterisk 
>> in section 6.3.
>>  I do not expect that indication to be of much value,  so I intended 
>> to propose to change its use to be a priority indicator. But it seems 
>> too tightly coupled to the use in language-matching in RFC 2616, so I 
>> abstain from proposing that and instead with hesitation propose that 
>> we include the q= factor notation from RFC 2616 for indicating 
>> preference.
>>
>>     The quality value defaults to "q=1" and has the same syntax and 
>> usage rules as for 'Accept-Language' in RFC 2616 [RFC2616].
>>
>>>>   The reasoning about implementability need a description about 
>>>> what version of the negotiating-human-language draft it refers to. 
>>>> We hope to improve, so we get "possible" on nearly all cases.
>>>>
>>>>   1. A coding for absolute level of preference for a 
>>>> modality-language combination in three levels: preferred, can-do, 
>>>> last-resort. Shall we explicit using words, or cryptic, using * and 
>>>> other special characters?
>>  Changed to q-value above
>>>>
>>>> together with absolute coding of preference shall be used, 
>>>> including some default rule for when no absolute coding is provided.
>>  What is said for dual modalities in 6.2 just below the change 
>> proposal above may be sufficient.
>>>>
>>>>
>>>>   The first case would mean that "I want to talk English" and "I 
>>>> want to read English text" shall be answered with "I want to listen 
>>>> to spoken English" and "I will type English" to get a match , The 
>>>> second case would mean that "I want to talk English" and "I want to 
>>>> read English text" would be answered with "I accept that you talk 
>>>> English" and "I accept that you will read English text" thus 
>>>> sending attributes as if coded from the offering party to get a match.
>>>>   The first case is more evident for the user, while the second 
>>>> case is easier to parse and check for a match.
>>  In 6.2 we have the rule that both the offeror and the answering 
>> party indicate values from their own point of view. I think that is 
>> doable.
>>>>
>>>>   4. A conclusion that need for speech-to-speech relay services is 
>>>> out of scope and need to be solved by other indications. Do anyone 
>>>> have ideas for such indications? Call-Info with purpose and URI to 
>>>> a suitable service? Make a REFER to bring in the service? Call with 
>>>> a URI-list? ( Yes, it is out of scope, but I am interested to have 
>>>> an agreed best practice solutions for it.)
>>  We take that separately and concentrate on the preference scope to 
>> cover all modalities here.
>>
>>  /Gunnar
>>>>
>>>>   Regards
>>>>
>>>>   Gunnar
>>>>
>>>>
>>>>>   Just a quick reminder that the IETF95 document submission 
>>>>> deadline is coming up fast (March 21st). I am going to submit the 
>>>>> use cases draft before then with the use cases I have collected 
>>>>> from the last meeting. If you want to see what we have so far then 
>>>>> see the link below (excuse the xml):
>>>>>
>>>>>
>>>>>   With regards to our two other documents, I believe the only 
>>>>> issue we have is regarding the dual modality use case, and the 
>>>>> difficulty of dealing with this within real-time communications 
>>>>> (this obviously only applies to 
>>>>> draft-ietf-slim-negotiating-human-language-00). My question to you 
>>>>> all is: do you have any other outstanding issues with either 
>>>>> draft? If not, we should be in a state to clean them up and publish.
>>>>>
>>>>>   Bernard and I are having a chairs chat next week so we can 
>>>>> discuss plans for IETF95 and the document status, so please let us 
>>>>> know before the end of Tuesday next week as to whether you have 
>>>>> any issues you wish to raise.
>>>>>
>>>>>   Thanks everyone!
>>>>>
>>>>>
>>>>>   Natasha
>>>>>
>>>>>
>>>>>   Natasha Rooney | Technologist, Web and Internet, W3C & IETF | 
>>>>> GSMA | <mailto:[email-masked]> [email-masked] | +44 (0) 7730 
>>>>> 219 765 | @thisNatasha | Skype: 
>>>>>>   We are 1 month and 1 day away from the start of IETF95! Gasp! 
>>>>>> We have some work to get on with before IETF95, where we will 
>>>>>> have a very short (and hopefully fruitful meeting!) discussing 
>>>>>> the last issues we have remaining.
>>>>>>
>>>>>>   I am going to be working on finishing the use cases document 
>>>>>> from now until IETF95. Please submit any issues or pull requests 
>>>>>> here? I remember that we were still discussing it and no 
>>>>>> decisions had been made - is this correct? On discussions with 
>>>>>> other IETF attendees many said that dual modality - whilst 
>>>>>> supported by use cases - is awfully difficult to implement, is 
>>>>>> this the same as the thoughts within this group?
>>>>>>
>>>>>>
>>>>>>   Natasha Rooney | Technologist, Web and Internet, W3C & IETF | 
>>>>>> GSMA | <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>[email-masked] | +44 (0) 7730 219 765 
>>>>>> 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 
>>>>> 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

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 16 Mar 2016 06:13:04 +0100

Hi Natasha and all,

I have a couple of suggestions for the use cases document:

1. In introduction, the words "real-time" and "necessary" are misspelled.

2. At the end of the introduction, I suggest the addition of:
"For each use case a 'Result' is provided, indicating the 
implementability of the use case based on draft version 
draft-ietf-slim-negotiating-human-language-00 "

3. The last line in section 3, Final comments look strange and should be 
changed to:
"There is no clear need for explicit grouping of language/modality 
indications."

4. In the introduction, it looks as if the document contains  both 
real-time and non-real-time use cases. If only real-time use cases are 
provided, then the introduction needs adaptation.

  /Gunnar

---

From: Brian Rosen <[email-masked]>
Date: Wed, 16 Mar 2016 14:38:11 -0400

I really don’t think that the complexity this introduces is worth the benefit, and I would prefer not to include it.  I also don’t think it works.  You want a grouping of media and language, with a preference on the grouping, not a simple priority on language.

Brian

> On Mar 15, 2016, at 7:20 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> Hi Randall,
> 
>> I think adding q= factor is much more complexity than is needed, and I remain unconvinced that we must have a preference indication at the start. I don't see that use cases are impossible without it.  It seems to me that the only difference it makes is to skip establishing some requested media streams if others are established.  I suspect that in most cases, the ones that could be skipped would be the easier ones (without relay/interpretation services).  Having an extra text or audio stream that is not used is not a big deal.
> I agree that adding the q-factor was not what I originally thought of as the solution.  But since I realised that we could not reuse the * -mark of the less-needed indication of Advisory vs required for this purpose I thought it was best to reuse another already existing coding. You are welcome to propose another alternative.
> Because we need a preference indication that is independent of media. I have called it "absolute preference", but that might not be the best words. It can be solved with a relative preference. The important thing is that it is about preference regardless of media
> You have specified one preference order within each media, but that is not sufficient.
> It is essential to be able to specify e.g. "I prefer to speak but can accept to type".
> And to indicate what modality/language combination is your favourite among possible combinations.
> 
> And it is not primarily about establishing media streams, it is about connecting the right persons and services to the call and have an indication in what modality and language to handle the call.
> 
> With the long turn-around-times in IETF I absolutely do not want to wait one generation before we satisfy this need.
> 
> Can we accept the q-factor or invent something new, e.g.  "; hi" for the highest preferred ones.
> 
>> If we keep the draft very simple to start with, then after we have some deployment experience, we can create a revision or an extension that adds the features that we found we need, in the way we found we need them.  In my experience, this is a better approach than trying to think of all aspects of the solution at the start, since doing so inevitably adds complexity and adds features in ways that turn out to not be ideal.
>> 
>> So, I would like to avoid adding preference now, but would be happy to work on an update or extension in the future if we find that we need it.
>> 
>>>> In the interest of keeping the draft as simple as possible for the initial version, I do not think we need to add the absolute level of preference that you suggest.
>>> And I think the draft will not be sufficiently usable without a mechanism to indicate absolute preference in a way so that the preference between languages and modalities in different media is indicated.
>>> For example I prefer to talk and hear spoken English in audio, but can accept to type and read English text.
>>> or another example:
>>> I prefer to talk and hear spoken French in audio but can accept to sign and see French sign language in video.
>>> 
>>> Without a way to make the distinction, we give no clue to the other party on why language is indicated in more than one media. Are all desired or not?
>>> And if you cannot indicate an option with lower preference then you may lose calls or get relay services invoked when they are not needed, wasting resources and making the calls less direct and less personal.
>>> 
>>> We could probably do with just two levels of preference: Preferred and possible.
>>> While searching in https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00
>>> for a possiblity to include that in the syntax without increasing complexity, I saw the Advisory vs Required indication by an asterisk in section 6.3.
>>> I do not expect that indication to be of much value,  so I intended to propose to change its use to be a priority indicator. But it seems too tightly coupled to the use in language-matching in RFC 2616, so I abstain from proposing that and instead with hesitation propose that we include the q= factor notation from RFC 2616 for indicating preference.
>>> 
>>> -------------------------------------current text in 6.2-------------------------------------------------
>>> 
>>> -------------------------------------proposed changed text in 6.2----------------------------------
>>> 
>>>>>  The reasoning about implementability need a description about what version of the negotiating-human-language draft it refers to. We hope to improve, so we get "possible" on nearly all cases.
>>>>> 
>>>>>  1. A coding for absolute level of preference for a modality-language combination in three levels: preferred, can-do, last-resort. Shall we explicit using words, or cryptic, using * and other special characters?
>>> Changed to q-value above
>>>>> 
>>>>>  2. A clear interpreting rule, saying that for needs of two modalities, one in each direction, the directional attributes together with absolute coding of preference shall be used, including some default rule for when no absolute coding is provided.
>>> What is said for dual modalities in 6.2 just below the change proposal above may be sufficient.
>>>>> 
>>>>> 
>>>>>  3. A description of offer-answer handling rules, making it very clear if the attributes in the answer indicate capabilities and preferences from the point of view of the party sending the SDP, or from the point of view of the offering party.
>>>>>  The first case would mean that "I want to talk English" and "I want to read English text" shall be answered with "I want to listen to spoken English" and "I will type English" to get a match , The second case would mean that "I want to talk English" and "I want to read English text" would be answered with "I accept that you talk English" and "I accept that you will read English text" thus sending attributes as if coded from the offering party to get a match.
>>>>>  The first case is more evident for the user, while the second case is easier to parse and check for a match.
>>> In 6.2 we have the rule that both the offeror and the answering party indicate values from their own point of view. I think that is doable.
>>>>> 
>>>>>  4. A conclusion that need for speech-to-speech relay services is out of scope and need to be solved by other indications. Do anyone have ideas for such indications? Call-Info with purpose and URI to a suitable service? Make a REFER to bring in the service? Call with a URI-list? ( Yes, it is out of scope, but I am interested to have an agreed best practice solutions for it.)
>>> We take that separately and concentrate on the preference scope to cover all modalities here.
>>> 
>>> /Gunnar
>>>>> 
>>>>>  Regards
>>>>> 
>>>>>  Gunnar
>>>>> 
>>>>> 
>>>>>>  Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | <mailto:[email-masked]> [email-masked] | +44 (0) 7730 219 765 | @thisNatasha | Skype: <mailto:[email-masked]>[email-masked]
>>>>>> 
>>>>>>>  On Mar 2, 2016, at 4:37 PM, Natasha Rooney <<mailto:[email-masked]>[email-masked]> wrote:
>>>>>>> 
>>>>>>>  Hi all!
>>>>>>> 
>>>>>>>  Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | <mailto:[email-masked]> <mailto:[email-masked]>[email-masked] | +44 (0) 7730 219 765 | @thisNatasha | Skype: <mailto:[email-masked]>[email-masked]
>>>>>>> 
>>>>>>> 
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288
> 
> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 16 Mar 2016 19:52:17 +0100

Den 2016-03-16 kl. 19:38, skrev Brian Rosen:
> I really don’t think that the complexity this introduces is worth the 
> benefit, and I would prefer not to include it.  I also don’t think it 
> works.  You want a grouping of media and language, with a preference 
> on the grouping, not a simple priority on language.
SDP groupings would introduce even more complexity and we would not see 
any implementations.

What we need is a grouping rule saying that if a language and modality 
is indicated for one direction and a certain level of preference, then 
it shall be regarded to be preferred to be used together with a language 
and modality in the other direction with the same level of preference.

It will be easy to parse for matches according to that rule.

Are there any suggestions for preference coding other than q=  ?

Gunnar
>
> Brian
>
>> On Mar 15, 2016, at 7:20 PM, Gunnar Hellström 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Randall,
>>
>>> I think adding q= factor is much more complexity than is needed, and 
>>> I remain unconvinced that we must have a preference indication at 
>>> the start. I don't see that use cases are impossible without it.  It 
>>> seems to me that the only difference it makes is to skip 
>>> establishing some requested media streams if others are established. 
>>>  I suspect that in most cases, the ones that could be skipped would 
>>> be the easier ones (without relay/interpretation services).  Having 
>>> an extra text or audio stream that is not used is not a big deal.
>> I agree that adding the q-factor was not what I originally thought of 
>> as the solution.  But since I realised that we could not reuse the * 
>> -mark of the less-needed indication of Advisory vs required for this 
>> purpose I thought it was best to reuse another already existing 
>> coding. You are welcome to propose another alternative.
>> Because we need a preference indication that is independent of media. 
>> I have called it "absolute preference", but that might not be the 
>> best words. It can be solved with a relative preference. The 
>> important thing is that it is about preference regardless of media
>> With the long turn-around-times in IETF I absolutely do not want to 
>> wait one generation before we satisfy this need.
>>
>>> need them.  In my experience, this is a better approach than trying 
>>> to think of all aspects of the solution at the start, since doing so 
>>> inevitably adds complexity and adds features in ways that turn out 
>>> to not be ideal.
>>>
>>> So, I would like to avoid adding preference now, but would be happy 
>>> to work on an update or extension in the future if we find that we 
>>> need it.
>>>
>>>>> initial version, I do not think we need to add the absolute level 
>>>>> of preference that you suggest.
>>>> complexity, I saw the Advisory vs Required indication by an 
>>>> asterisk in section 6.3.
>>>> to propose to change its use to be a priority indicator. But it 
>>>> seems too tightly coupled to the use in language-matching in RFC 
>>>> 2616, so I abstain from proposing that and instead with hesitation 
>>>> propose that we include the q= factor notation from RFC 2616 for 
>>>> indicating preference.
>>>>
>>>>>> what version of the negotiating-human-language draft it refers 
>>>>>> to. We hope to improve, so we get "possible" on nearly all cases.
>>>>>>
>>>>>> last-resort. Shall we explicit using words, or cryptic, using * 
>>>>>> preferences from the point of view of the party sending the SDP, 
>>>>>> or from the point of view of the offering party.
>>>>>> want to read English text" shall be answered with "I want to 
>>>>>> listen to spoken English" and "I will type English" to get a 
>>>>>> match , The second case would mean that "I want to talk English" 
>>>>>> and "I want to read English text" would be answered with "I 
>>>>>> accept that you talk English" and "I accept that you will read 
>>>>>> English text" thus sending attributes as if coded from the 
>>>>>> offering party to get a match.
>>>>>> out of scope and need to be solved by other indications. Do 
>>>>>> anyone have ideas for such indications? Call-Info with purpose 
>>>>>> and URI to a suitable service? Make a REFER to bring in the 
>>>>>> service? Call with a URI-list? ( Yes, it is out of scope, but I 
>>>>>> am interested to have an agreed best practice solutions for it.)
>>>>>>> deadline is coming up fast (March 21st). I am going to submit 
>>>>>>> the use cases draft before then with the use cases I have 
>>>>>>> collected from the last meeting. If you want to see what we have 
>>>>>>> so far then see the link below (excuse the xml):
>>>>>>>
>>>>>>>
>>>>>>> draft-ietf-slim-negotiating-human-language-00). My question to 
>>>>>>> you all is: do you have any other outstanding issues with either 
>>>>>>> discuss plans for IETF95 and the document status, so please let 
>>>>>>> us know before the end of Tuesday next week as to whether you 
>>>>>>> have any issues you wish to raise.
>>>>>>>
>>>>>>>  Thanks everyone!
>>>>>>>
>>>>>>>
>>>>>>>  Natasha
>>>>>>>
>>>>>>>
>>>>>>> GSMA | <mailto:[email-masked]> [email-masked] 
>>>>>>> <mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha 
>>>>>>> | Skype: <mailto:[email-masked]>[email-masked] 
>>>>>>> <mailto:[email-masked]>
>>>>>>>
>>>>>>>> <<mailto:[email-masked]>[email-masked] 
>>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>>
>>>>>>>>  Hi all!
>>>>>>>>
>>>>>>>> from now until IETF95. Please submit any issues or pull 
>>>>>>>> requests to the github repo or tell me directly:
>>>>>>>>
>>>>>>>>
>>>>>>>> <mailto:[email-masked]>[email-masked] 
>>>>>>>> <mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha 
>>>>>>>> | Skype: <mailto:[email-masked]>[email-masked] 
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>
>>>>>>>>
>>>>>>>>  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.
>>>>>>>>
>>>>>>>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>>>>
>>>>>>>>
>>>>>>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>>>>>>>
>>>>>>>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 16 Mar 2016 11:59:29 -0700

Thank you, Doug and Brian, for your thoughts.

Based on the discussion, I propose that we do not 
add an additional preference mechanism to the 
draft.

At 2:38 PM -0400 3/16/16, Brian Rosen wrote:

>  I really don't think that the complexity this 
> introduces is worth the benefit, and I would 
> prefer not to include it.  I also don't think 
> it works.  You want a grouping of media and 
> language, with a preference on the grouping, 
> not a simple priority on language.
>
>  Brian
>
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>  Hi Randall,
>>
>>>  I think adding q= factor is much more 
>>> complexity than is needed, and I remain 
>>> unconvinced that we must have a preference 
>>> indication at the start. I don't see that use 
>>> cases are impossible without it.  It seems to 
>>> me that the only difference it makes is to 
>>> skip establishing some requested media 
>>> streams if others are established.  I suspect 
>>> that in most cases, the ones that could be 
>>> skipped would be the easier ones (without 
>>> relay/interpretation services).  Having an 
>>> extra text or audio stream that is not used 
>>> is not a big deal.
>>>
>>  I agree that adding the q-factor was not what 
>> I originally thought of as the solution.  But 
>> since I realised that we could not reuse the * 
>> -mark of the less-needed indication of 
>> Advisory vs required for this purpose I 
>> thought it was best to reuse another already 
>> existing coding. You are welcome to propose 
>> another alternative.
>>  Because we need a preference indication that 
>> is independent of media. I have called it 
>> "absolute preference", but that might not be 
>> the best words. It can be solved with a 
>> relative preference. The important thing is 
>> that it is about preference regardless of media
>>  And to indicate what modality/language 
>> combination is your favourite among possible 
>> combinations.
>>
>>  And it is not primarily about establishing 
>> media streams, it is about connecting the 
>> right persons and services to the call and 
>> have an indication in what modality and 
>> language to handle the call.
>>
>>  With the long turn-around-times in IETF I 
>> absolutely do not want to wait one generation 
>> before we satisfy this need.
>>
>>  Can we accept the q-factor or invent something 
>> new, e.g.  "; hi" for the highest preferred 
>> ones.
>>
>>>  If we keep the draft very simple to start 
>>> with, then after we have some deployment 
>>> experience, we can create a revision or an 
>>> extension that adds the features that we 
>>> found we need, in the way we found we need 
>>> them.  In my experience, this is a better 
>>> approach than trying to think of all aspects 
>>> of the solution at the start, since doing so 
>>> inevitably adds complexity and adds features 
>>>  So, I would like to avoid adding preference 
>>> now, but would be happy to work on an update 
>>> or extension in the future if we find that we 
>>> need it.
>>>
>>>>>  In the interest of keeping the draft as 
>>>>> simple as possible for the initial version, 
>>>>> I do not think we need to add the absolute 
>>>>> level of preference that you suggest.
>>>>>
>>>>  And I think the draft will not be 
>>>> sufficiently usable without a mechanism to 
>>>> indicate absolute preference in a way so 
>>>> that the preference between languages and 
>>>> modalities in different media is indicated.
>>>>  Without a way to make the distinction, we 
>>>> give no clue to the other party on why 
>>>> language is indicated in more than one 
>>>> media. Are all desired or not?
>>>>  And if you cannot indicate an option with 
>>>> lower preference then you may lose calls or 
>>>> get relay services invoked when they are not 
>>>> needed, wasting resources and making the 
>>>> calls less direct and less personal.
>>>>
>>>> <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00>https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00
>>>>  for a possiblity to include that in the 
>>>> syntax without increasing complexity, I saw 
>>>> the Advisory vs Required indication by an 
>>>> asterisk in section 6.3.
>>>>  I do not expect that indication to be of 
>>>> much value,  so I intended to propose to 
>>>> change its use to be a priority indicator. 
>>>> But it seems too tightly coupled to the use 
>>>> in language-matching in RFC 2616, so I 
>>>> abstain from proposing that and instead with 
>>>> hesitation propose that we include the q= 
>>>> factor notation from RFC 2616 for indicating 
>>>> preference.
>>>>
>>>>     offerer wishes to receive using the 
>>>> media. The q-values represent a preference 
>>>> level
>>>>     The quality value defaults to "q=1" and 
>>>> has the same syntax and usage rules as for 
>>>>     If more than one language is specified 
>>>> for the same media and direction with the 
>>>> same q-value,
>>>>>>   The reasoning about implementability need 
>>>>>> a description about what version of the 
>>>>>> combination in three levels: preferred, 
>>>>>> can-do, last-resort. Shall we explicit 
>>>>>> using words, or cryptic, using * and other 
>>>>>> special characters?
>>>>>>
>>>>  Changed to q-value above
>>>>
>>>>>>
>>>>>> together with absolute coding of 
>>>>>> preference shall be used, including some 
>>>>>> default rule for when no absolute coding 
>>>>>> is provided.
>>>>>>
>>>>>> rules, making it very clear if the 
>>>>>> attributes in the answer indicate 
>>>>>> capabilities and preferences from the 
>>>>>> point of view of the party sending the 
>>>>>> SDP, or from the point of view of the 
>>>>>> offering party.
>>>>>> would mean that "I want to talk English" 
>>>>>> and "I want to read English text" would be 
>>>>>> English text" thus sending attributes as 
>>>>>> if coded from the offering party to get a 
>>>>>> match.
>>>>>>   The first case is more evident for the 
>>>>>> user, while the second case is easier to 
>>>>>> parse and check for a match.
>>>>>>
>>>>  In 6.2 we have the rule that both the 
>>>> offeror and the answering party indicate 
>>>> values from their own point of view. I think 
>>>> that is doable.
>>>>
>>>>>>
>>>>>> indications? Call-Info with purpose and 
>>>>>> URI to a suitable service? Make a REFER to 
>>>>>> bring in the service? Call with a 
>>>>>> URI-list? ( Yes, it is out of scope, but I 
>>>>  We take that separately and concentrate on 
>>>> the preference scope to cover all modalities 
>>>> here.
>>>>
>>>>  /Gunnar
>>>>
>>>>>>
>>>>>>   Regards
>>>>>>
>>>>>>   Gunnar
>>>>>>
>>>>>>
>>>>>>> fast (March 21st). I am going to submit 
>>>>>>> the use cases draft before then with the 
>>>>>>> use cases I have collected from the last 
>>>>>>> meeting. If you want to see what we have 
>>>>>>> <<https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml>https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml><https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml>https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml 
>>>>>>>
>>>>>>>   Our Document Status
>>>>>>>   With regards to our two other documents, 
>>>>>>> I believe the only issue we have is 
>>>>>>> regarding the dual modality use case, and 
>>>>>>> the difficulty of dealing with this 
>>>>>>> within real-time communications (this 
>>>>>>> obviously only applies to 
>>>>>>> My question to you all is: do you have 
>>>>>>> any other outstanding issues with either 
>>>>>>>   Bernard and I are having a chairs chat 
>>>>>>> next week so we can discuss plans for 
>>>>>>> IETF95 and the document status, so please 
>>>>>>> let us know before the end of Tuesday 
>>>>>>> next week as to whether you have any 
>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]> 
>>>>>>> | +44 (0) 7730 219 765 | @thisNatasha | 
>>>>>>> Skype: 
>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>>>
>>>>>>>> <<<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>   Hi all!
>>>>>>>>
>>>>>>>> start of IETF95! Gasp! We have some work 
>>>>>>>> to get on with before IETF95, where we 
>>>>>>>> will have a very short (and hopefully 
>>>>>>>> fruitful meeting!) discussing the last 
>>>>>>>> <<https://ietf.org/meeting/95/index.html>https://ietf.org/meeting/95/index.html><https://ietf.org/meeting/95/index.html>https://ietf.org/meeting/95/index.html 
>>>>>>>>
>>>>>>>>   I am going to be working on finishing 
>>>>>>>> the use cases document from now until 
>>>>>>>> IETF95. Please submit any issues or pull 
>>>>>>>> <<https://github.com/ietf-slim-wg/slim-use-cases/>https://github.com/ietf-slim-wg/slim-use-cases/><https://github.com/ietf-slim-wg/slim-use-cases/>https://github.com/ietf-slim-wg/slim-use-cases/ 
>>>>>>>>
>>>>>>>>   With our other two documents I believe 
>>>>>>>> the modality issues is still at large. 
>>>>>>>> Can someone catch me up on the last 
>>>>>>>> discussions here? I remember that we 
>>>>>>>> were still discussing it and no 
>>>>>>>> decisions had been made - is this 
>>>>>>>> correct? On discussions with other IETF 
>>>>>>>> attendees many said that dual modality - 
>>>>>>>> whilst supported by use cases - is 
>>>>>>>> awfully difficult to implement, is this 
>>>>>>>> <<https://datatracker.ietf.org/wg/slim/documents/>https://datatracker.ietf.org/wg/slim/documents/><https://datatracker.ietf.org/wg/slim/documents/>https://datatracker.ietf.org/wg/slim/documents/ 
>>>>>>>>
>>>>>>>>   Thanks all!
>>>>>>>>
>>>>>>>>   Natasha
>>>>>>>>
>>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]> 
>>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked] 
>>>>>>>> | +44 (0) 7730 219 765 | @thisNatasha | 
>>>>>>>> Skype: 
>>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>> <<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim><https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim 
>>>>>>>>
>>>>>>>
>>>>>>> anyone; please reply to this email or 
>>>>>>> call +44 207 356 0600 and highlight the 
>>>>>>> error.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><mailto:[email-masked]>[email-masked]
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>>> <<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim><https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim 
>>>>>>>
>>>>>>
>>>>>>
>>>>  <mailto:[email-masked]>[email-masked]
>>>>  +46 708 204 288
>>>>
>>  <mailto:[email-masked]>[email-masked]
>>  +46 708 204 288
>>

-------------- Randomly selected tag: ---------------
It takes a wonderful brain and exquisite senses to produce a few
stupid ideas.                                        --Santayana

---

From: Randall Gellens <[email-masked]>
Date: Wed, 16 Mar 2016 13:02:22 -0700

I think we can proceed without a new preference 
mechanism.  As I see it, the worst case is we end 
up with unused media streams.

At 7:52 PM +0100 3/16/16, Gunnar Hellström wrote:

>  SDP groupings would introduce even more 
> complexity and we would not see any 
> implementations.
>
>  What we need is a grouping rule saying that if 
> a language and modality is indicated for one 
> direction and a certain level of preference, 
> then it shall be regarded to be preferred to be 
> used together with a language and modality in 
> the other direction with the same level of 
> preference.
>
>>>> indication at the start. I don't see that 
>>>> use cases are impossible without it. It 
>>>> seems to me that the only difference it 
>>>> suspect that in most cases, the ones that 
>>>> could be skipped would be the easier ones 
>>>> (without relay/interpretation services). 
>>>> Having an extra text or audio stream that is 
>>>> not used is not a big deal.
>>>>
>>> since I realised that we could not reuse the 
>>> * -mark of the less-needed indication of 
>>>  You have specified one preference order 
>>> within each media, but that is not sufficient.
>>>  Can we accept the q-factor or invent 
>>> something new, e.g. "; hi" for the highest 
>>> preferred ones.
>>>
>>>> or extension in the future if we find that 
>>>> we need it.
>>>>
>>>>>> simple as possible for the initial 
>>>>>> version, I do not think we need to add the 
>>>>>> absolute level of preference that you 
>>>>>> suggest.
>>>>>>
>>>>>  For example I prefer to talk and hear 
>>>>> spoken English in audio, but can accept to 
>>>>> type and read English text.
>>>>>  or another example:
>>>>> get relay services invoked when they are 
>>>>> not needed, wasting resources and making 
>>>>> the calls less direct and less personal.
>>>>>
>>>>> abstain from proposing that and instead 
>>>>> with hesitation propose that we include the 
>>>>> q= factor notation from RFC 2616 for 
>>>>> indicating preference.
>>>>>
>>>>>>> negotiating-human-language draft it 
>>>>>>> refers to. We hope to improve, so we get 
>>>>>>> "possible" on nearly all cases.
>>>>>>>
>>>>>>> using words, or cryptic, using * and 
>>>>>  What is said for dual modalities in 6.2 
>>>>> just below the change proposal above may be 
>>>>> sufficient.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> listen to spoken English" and "I will 
>>>>>>> type English" to get a match , The second 
>>>>>>> case would mean that "I want to talk 
>>>>>>> English" and "I want to read English 
>>>>>>> text" would be answered with "I accept 
>>>>>>> that you talk English" and "I accept that 
>>>>>>> you will read English text" thus sending 
>>>>> values from their own point of view. I 
>>>>> think that is doable.
>>>>>
>>>>>>>
>>>>>>> indications. Do anyone have ideas for 
>>>>>>> such indications? Call-Info with purpose 
>>>>>>> and URI to a suitable service? Make a 
>>>>>>> REFER to bring in the service? Call with 
>>>>>>> a URI-list? ( Yes, it is out of scope, 
>>>>>>> but I am interested to have an agreed 
>>>>>>> best practice solutions for it.)
>>>>>>>
>>>>> the preference scope to cover all 
>>>>> modalities here.
>>>>>
>>>>>  /Gunnar
>>>>>
>>>>>>>
>>>>>>>  Regards
>>>>>>>
>>>>>>>  Gunnar
>>>>>>>
>>>>>>>
>>>>>>>> document submission deadline is coming 
>>>>>>>> up fast (March 21st). I am going to 
>>>>>>>> submit the use cases draft before then 
>>>>>>>> with the use cases I have collected from 
>>>>>>>> the last meeting. If you want to see 
>>>>>>>> what we have so far then see the link 
>>>>>>>> below (excuse the xml):
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>> <<https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml>https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml><>https://github.com/ietf-slim-wg/slim-use-cases/blob/master/draft-ietf-slim-use-cases-latest.xml
>>>>>>>>
>>>>>>>>  Our Document Status
>>>>>>>> regarding the dual modality use case, 
>>>>>>>> and the difficulty of dealing with this 
>>>>>>>> IETF95 and the document status, so 
>>>>>>>> please let us know before the end of 
>>>>>>>> Tuesday next week as to whether you have 
>>>>>>>> <<>mailto:[email-masked]> 
>>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><>[email-masked]
>>>>>>>>
>>>>>>>>> <<<>mailto:[email-masked]><>[email-masked]> 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>  Hi all!
>>>>>>>>>
>>>>>>>>> start of IETF95! Gasp! We have some 
>>>>>>>>> work to get on with before IETF95, 
>>>>>>>>> where we will have a very short (and 
>>>>>>>>> hopefully fruitful meeting!) discussing 
>>>>>>>>> <<https://ietf.org/meeting/95/index.html>https://ietf.org/meeting/95/index.html><>https://ietf.org/meeting/95/index.html
>>>>>>>>>
>>>>>>>>> IETF95. Please submit any issues or 
>>>>>>>>> pull requests to the github repo or 
>>>>>>>>> tell me directly:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>> <<https://github.com/ietf-slim-wg/slim-use-cases/>https://github.com/ietf-slim-wg/slim-use-cases/><>https://github.com/ietf-slim-wg/slim-use-cases/
>>>>>>>>>
>>>>>>>>> attendees many said that dual modality 
>>>>>>>>> - whilst supported by use cases - is 
>>>>>>>>> <<https://datatracker.ietf.org/wg/slim/documents/>https://datatracker.ietf.org/wg/slim/documents/><>https://datatracker.ietf.org/wg/slim/documents/
>>>>>>>>>
>>>>>>>>>  Thanks all!
>>>>>>>>>
>>>>>>>>>  Natasha
>>>>>>>>>
>>>>>>>>> <<>mailto:[email-masked]> 
>>>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><>[email-masked] 
>>>>>>>>> <<mailto:[email-masked]>mailto:[email-masked]><>[email-masked]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>  <<mailto:[email-masked]>mailto:[email-masked]><>[email-masked]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 
>>>>>>>>> <<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim><>https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>>
>>>>>>>>
>>>>>>>>  <<mailto:[email-masked]>mailto:[email-masked]><>[email-masked]
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>> <<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim><>https://www.ietf.org/mailman/listinfo/slim
>>>>>>>>
>>>>>>>
>>>>>>>

-------------- Randomly selected tag: ---------------
If Murphy's Law can go wrong, it will.

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 16 Mar 2016 22:13:23 +0100

Den 2016-03-16 kl. 21:02, skrev Randall Gellens:
> I think we can proceed without a new preference mechanism.  As I see 
> it, the worst case is we end up with unused media streams.
This is not about negotiating media streams, it is about having the 
right people taking the calls and adding additional services when needed.
Please read the use cases document again and understand why we need the 
preference indication to be across modalities.
The idea of the use case document was to make clear what was supported 
and not with the different mechanisms, so that we could create and 
include sufficient mechanisms to cover the use cases we find that we 
want to support.

I am satisfied with leaving invocation of speech-to-speech relay 
services without support from our mechanisms, but not the other use cases.

Today ETSI published a report where among other things there is quite 
high hopes tied to SLIM for providing pieces for the solution of getting 
the right parties involved in emergency service calls.
See 
http://www.etsi.org/deliver/etsi_tr/103200_103299/103201/01.01.01_60/tr_103201v010101p.pdf

So, we have expectations on us.

Gunnar

>>>  I really don't think that the complexity this introduces is worth 
>>> the benefit, and I would prefer not to include it. I also don't 
>>> think it works. You want a grouping of media and language, with a 
>>> preference on the grouping, not a simple priority on language.
>>>
>>  SDP groupings would introduce even more complexity and we would not 
>> see any implementations.
>>
>>  What we need is a grouping rule saying that if a language and 
>> modality is indicated for one direction and a certain level of 
>> preference, then it shall be regarded to be preferred to be used 
>> together with a language and modality in the other direction with the 
>> same level of preference.
>>
>>>>>  I think adding q= factor is much more complexity than is needed, 
>>>>> and I remain unconvinced that we must have a preference indication 
>>>>> at the start. I don't see that use cases are impossible without 
>>>>> it. It seems to me that the only difference it makes is to skip 
>>>>> establishing some requested media streams if others are 
>>>>> established. I suspect that in most cases, the ones that could be 
>>>>> skipped would be the easier ones (without relay/interpretation 
>>>>> services). Having an extra text or audio stream that is not used 
>>>>> is not a big deal.
>>>>>
>>>>  I agree that adding the q-factor was not what I originally thought 
>>>> of as the solution. But since I realised that we could not reuse 
>>>> the * -mark of the less-needed indication of Advisory vs required 
>>>> for this purpose I thought it was best to reuse another already 
>>>> existing coding. You are welcome to propose another alternative.
>>>>  Because we need a preference indication that is independent of 
>>>> media. I have called it "absolute preference", but that might not 
>>>> be the best words. It can be solved with a relative preference. The 
>>>>  And it is not primarily about establishing media streams, it is 
>>>> about connecting the right persons and services to the call and 
>>>> have an indication in what modality and language to handle the call.
>>>>
>>>>  With the long turn-around-times in IETF I absolutely do not want 
>>>> to wait one generation before we satisfy this need.
>>>>
>>>>>  If we keep the draft very simple to start with, then after we 
>>>>> have some deployment experience, we can create a revision or an 
>>>>> extension that adds the features that we found we need, in the way 
>>>>> we found we need them. In my experience, this is a better approach 
>>>>> than trying to think of all aspects of the solution at the start, 
>>>>> since doing so inevitably adds complexity and adds features in 
>>>>> ways that turn out to not be ideal.
>>>>>
>>>>>  So, I would like to avoid adding preference now, but would be 
>>>>> happy to work on an update or extension in the future if we find 
>>>>> that we need it.
>>>>>
>>>>>>>  In the interest of keeping the draft as simple as possible for 
>>>>>>> the initial version, I do not think we need to add the absolute 
>>>>>>  For example I prefer to talk and hear spoken English in audio, 
>>>>>> but can accept to type and read English text.
>>>>>>  or another example:
>>>>>>  I prefer to talk and hear spoken French in audio but can accept 
>>>>>> to sign and see French sign language in video.
>>>>>>
>>>>>>  Without a way to make the distinction, we give no clue to the 
>>>>>> other party on why language is indicated in more than one media. 
>>>>>> Are all desired or not?
>>>>>>  And if you cannot indicate an option with lower preference then 
>>>>>> you may lose calls or get relay services invoked when they are 
>>>>>> not needed, wasting resources and making the calls less direct 
>>>>>> and less personal.
>>>>>>
>>>>>>  for a possiblity to include that in the syntax without 
>>>>>> increasing complexity, I saw the Advisory vs Required indication 
>>>>>> by an asterisk in section 6.3.
>>>>>>  I do not expect that indication to be of much value, so I 
>>>>>> intended to propose to change its use to be a priority indicator. 
>>>>>> But it seems too tightly coupled to the use in language-matching 
>>>>>> in RFC 2616, so I abstain from proposing that and instead with 
>>>>>> hesitation propose that we include the q= factor notation from 
>>>>>> RFC 2616 for indicating preference.
>>>>>>
>>>>>>>> modality-language combination in three levels: preferred, 
>>>>>>>> can-do, last-resort. Shall we explicit using words, or cryptic, 
>>>>>>>> using * and other special characters?
>>>>>>>>
>>>>>>  Changed to q-value above
>>>>>>
>>>>>>>>
>>>>>>>>  3. A description of offer-answer handling rules, making it 
>>>>>>>> very clear if the attributes in the answer indicate 
>>>>>>>> capabilities and preferences from the point of view of the 
>>>>>>>> party sending the SDP, or from the point of view of the 
>>>>>>>> offering party.
>>>>>>>> match , The second case would mean that "I want to talk 
>>>>>>>> English" and "I want to read English text" would be answered 
>>>>>>>> with "I accept that you talk English" and "I accept that you 
>>>>>>>> will read English text" thus sending attributes as if coded 
>>>>>>>> from the offering party to get a match.
>>>>>> party indicate values from their own point of view. I think that 
>>>>>> is doable.
>>>>>>
>>>>>>>>
>>>>>>>>  4. A conclusion that need for speech-to-speech relay services 
>>>>>>>> is out of scope and need to be solved by other indications. Do 
>>>>>>>>> collected from the last meeting. If you want to see what we 
>>>>>>>>> have so far then see the link below (excuse the xml):
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> difficulty of dealing with this within real-time 
>>>>>>>>> you all is: do you have any other outstanding issues with 
>>>>>>>>> either draft? If not, we should be in a state to clean them up 
>>>>>>>>> and publish.
>>>>>>>>>
>>>>>>>>> discuss plans for IETF95 and the document status, so please 
>>>>>>>>> let us know before the end of Tuesday next week as to whether 
>>>>>>>>> you have any issues you wish to raise.
>>>>>>>>>
>>>>>>>>>  Thanks everyone!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  Natasha
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> GSMA | <<>mailto:[email-masked]> 
>>>>>>>>> <mailto:[email-masked]>[email-masked] | +44 (0) 7730 219 
>>>>>>>>> 765 | @thisNatasha | Skype: 
>>>>>>>>>> <<<>mailto:[email-masked]><>[email-masked]> wrote:
>>>>>>>>>>
>>>>>>>>>>  Hi all!
>>>>>>>>>>
>>>>>>>>>>  We are 1 month and 1 day away from the start of IETF95! 
>>>>>>>>>> Gasp! We have some work to get on with before IETF95, where 
>>>>>>>>>> we will have a very short (and hopefully fruitful meeting!) 
>>>>>>>>>>  With our other two documents I believe the modality issues 
>>>>>>>>>> is still at large. Can someone catch me up on the last 
>>>>>>>>>> discussions here? I remember that we were still discussing it 
>>>>>>>>>> and no decisions had been made - is this correct? On 
>>>>>>>>>> discussions with other IETF attendees many said that dual 
>>>>>>>>>> modality - whilst supported by use cases - is awfully 
>>>>>>>>>> difficult to implement, is this the same as the thoughts 
>>>>>>>>>> within this group?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  Natasha Rooney | Technologist, Web and Internet, W3C & IETF 
>>>>>>>>>> | GSMA | <<>mailto:[email-masked]> 
>>>>>>>>>> | +44 (0) 7730 219 765 | @thisNatasha | Skype: 
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>

---

From: Natasha Rooney <[email-masked]>
Date: Thu, 17 Mar 2016 15:41:17 +0000

Changes have now been included with the PR from Bernard. Thanks Bernard and Gunnar!

Natasha

On Mar 16, 2016, at 5:13 AM, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

Hi Natasha and all,

2. At the end of the introduction, I suggest the addition of:
"For each use case a 'Result' is provided, indicating the implementability of the use case based on draft version  draft-ietf-slim-negotiating-human-language-00 "<https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-00>

3. The last line in section 3, Final comments look strange and should be changed to:
"There is no clear need for explicit grouping of language/modality indications."

4. In the introduction, it looks as if the document contains  both real-time and non-real-time use cases. If only real-time use cases are provided, then the introduction needs adaptation.

 /Gunnar

IETF95 Deadline

Our Document Status

Thanks everyone!

Natasha

Hi all!

Thanks all!

Natasha

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

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