Subject: [MMUSIC] Updated: Toronto time for human language draft discussion

From: Randall Gellens <[email-masked]>
Date: Sat, 19 Jul 2014 08:44:47 -0700

[[ The Doodle poll to find a time to meet in Toronto has been updated 
with two new time slots. ]]

Hi to everyone who participated in previous discussions about the 
human language negotiation draft.

I'd like to make progress on this draft.  I think meeting in Toronto 
can help that.  Please participate.

I created a Doodle poll to see if we can find a time in Toronto to 
meet face to face.

Doodle poll for time at Toronto to discuss open issues and moving 
forward with Human Language Negotiation: 
http://doodle.com/pm3mph6xa3m9kupp

Link to current version (-02) of draft: 
http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A logician saves the life of a space alien and is rewarded with
an offer to answer any question.  After a thought he asks: What
is the best question to ask and the correct answer to it?  After
a brief panic the alien consults her computer and says: The best
question to ask is the one you just did and the correct answer
to it is the one I gave.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sun, 20 Jul 2014 07:17:37 +0200

Yes, good idea to retry on this topic.
I cannot be there, but I hope there will be progress.

Te link did not work. Try this:
http://tools.ietf.org/id/draft-gellens-negotiating-human-language-02.txt

I see you set the topic for the meeting to mainly discuss where to place 
the language declarations, in SIP or SDP. How about other alternatives, 
more related to user profiles?
E.g. provide in SIP or other session establishment procedure a URI to a 
user profile record with the language preference and capability 
information.
For SIP, it can be made similar to how location by reference is provided 
according to RFC 6442. One benefit is that it can easily be carried over 
to other environments ( like WebRTC ).

Gunnar
------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46708204288

---

From: Randall Gellens <[email-masked]>
Date: Sun, 20 Jul 2014 05:56:58 -0700

At 7:17 AM +0200 7/20/14, Gunnar Hellstrom wrote:

>  I see you set the topic for the meeting to mainly discuss where to 
> place the language declarations, in SIP or SDP. How about other 
> alternatives, more related to user profiles?
>  E.g. provide in SIP or other session establishment procedure a URI 
> to a user profile record with the language preference and 
> capability information.
>  For SIP, it can be made similar to how location by reference is 
> provided according to RFC 6442. One benefit is that it can easily 
> be carried over to other environments ( like WebRTC ).

For real-time communications, I think it better to not rely on either 
party needing to fetch resources from external servers, as that 
introduces additional delay and failure cases.  Especially since one 
of the driving use cases is emergency calls, we don't want to add 
fragility.

>>  [[ The Doodle poll to find a time to meet in Toronto has been 
>> updated with two new time slots. ]]
>>
>>  I'd like to make progress on this draft.  I think meeting in 
>> Toronto can help that.  Please participate.
>>
>> <http://doodle.com/pm3mph6xa3m9kupp>http://doodle.com/pm3mph6xa3m9kupp
>>
>> <http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt>http://www.ietf.org/internet-drafts/draft-gellens-negotiating-human-language-02.txt

-------------- Randomly selected tag: ---------------
Citizens for corrupt government, unclean water, higher taxes,
unsafe streets, and poor schools.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sun, 20 Jul 2014 21:47:33 +0200

We need to collect the requirements before we decide on the mechanism.

I think we discussed them earlier, but they are not captured fully in 
the draft.

Here are some basic requirements:

Purpose: The declaration and negotiation of capabilities and preferences 
for modalities and languages shall make it possible to optimize call 
handling by routing calls to call handlers with most suitable 
capabilities or by including assisting services in the call to cover 
gaps in modality and language handling capability between the caller and 
the callee.

The modalities shall at least be: real-time text , message-wise text, 
speech, voice, sign language and speech-reading.

The capability and preference declaration shall enable declaration of 
more than one modality, and the relative preference between the modalities.

The capability and preference declaration shall enable declaration of 
more than one language per modality, and the relative preference between 
the languages within the modalities.

The capability and preference declaration shall enable declaration of 
different capabilities and preferences for production versus reception 
of language expression.

It shall be possible for servers along the route to take the decision on 
routing.

It shall be possible to indicate that an assisting service is included 
in a call, so that double invocation of assisting services is avoided.

This is a start. It can be further expanded.

Gunnar

------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46708204288
On 2014-07-20 14:56, Randall Gellens wrote:
>> to a user profile record with the language preference and capability 
>> information.
>> provided according to RFC 6442. One benefit is that it can easily be 
>> carried over to other environments ( like WebRTC ).
>