Subject: [Slim] [slim] #21 (negotiating-human-language): Add the text message modality to the realtime draft

From: "slim issue tracker" <[email-masked]>
Date: Wed, 17 Aug 2016 13:42:38 -0000

#21: Add the text message modality to the realtime draft

 There is a modality that we have not discussed at all yet. That is the
 "text message" modality. It is not really interactive, but very often used
 together with interactive media in a kind of slow pseudo-conversational
 mode. One implementation is MSRP that is specified by the m=message media.
 There seems to be some interest to extend our specification to handle that
 modality as well.

 Then the text message modality needs to be described and how it is
 implicitly identified in sdp both in the main media m=message and in a
 subchannel of a data channel.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-slim-
  [email-masked]        |  [email-masked]
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  negotiating-human-       |    Version:
  language                           |   Keywords:  message
 Severity:  In WG Last Call          |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/21>
slim <https://tools.ietf.org/slim/>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Aug 2016 09:55:25 -0400

I support adding text, but it should be sufficient to mention that the language tags can be applied to m=message sections.

I wouldn’t want to assume anything about future modalities, but maybe we could say something along the lines of “Application of the humintlang tags to SDP sections where human understandable media in specific languages is sent, such as m=application (e.g. WebRTC text media) or m=message (MSRP) is permitted”.  That might even cover something like a screen share where you might have slides in multiple media available.

I don’t want to be very explicit, so we can cover new media streams that have obvious meaning when we apply the tags without requiring every new m= to have text saying how this spec applies. 

Brian

> On Aug 17, 2016, at 9:42 AM, slim issue tracker <[email-masked]> wrote:
> 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 Aug 2016 21:31:17 -0700

This seems reasonable to me (adding brief mention of applicability to 
m=application and m=message).

--Randy

At 9:55 AM -0400 8/17/16, Brian Rosen wrote:

>  I support adding text, but it should be sufficient to mention that 
> the language tags can be applied to m=message sections.
>
>  I wouldn't want to assume anything about future modalities, but 
> maybe we could say something along the lines of "Application of the 
> humintlang tags to SDP sections where human understandable media in 
> specific languages is sent, such as m=application (e.g. WebRTC text 
> media) or m=message (MSRP) is permitted".  That might even cover 
> something like a screen share where you might have slides in 
> multiple media available.
>
>  I don't want to be very explicit, so we can cover new media streams 
> that have obvious meaning when we apply the tags without requiring 
> every new m= to have text saying how this spec applies.
>
>  Brian
>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Snacktrek, n.:
    The peculiar habit, when searching for a snack, of constantly
returning to the refrigerator in hopes that something new will have
materialized.                                --Rich Hall, "Sniglets"

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Aug 2016 22:29:41 -0700

Addition of some text on screen sharing seems like a good idea. There are
differences between screen sharing/remote control implemented with
m=application (e.g. RDP screen sharing) and WebRTC screen sharing, which is
handled with m=video.

In WebRTC scree sharing, an offer might include one m=video line with
a=sendonly advertising the ability to send English (the screen share) and
another m=video line with a=sendrecv (generated by a webcam), advertising
the ability to send and receive ASL. It may not be obvious from the SDP
that one of the m=video lines is a screen share and even if the  O/A
exchange accepts the screen sharing m line (without both sides even knowing
what it is for), it might or might not be used.

On Aug 17, 2016 6:55 AM, "Brian Rosen" <[email-masked]> wrote:

> I support adding text, but it should be sufficient to mention that the
> language tags can be applied to m=message sections.
>
> I wouldn’t want to assume anything about future modalities, but maybe we
> could say something along the lines of “Application of the humintlang tags
> to SDP sections where human understandable media in specific languages is
> sent, such as m=application (e.g. WebRTC text media) or m=message (MSRP) is
> permitted”.  That might even cover something like a screen share where you
> might have slides in multiple media available.
>
> I don’t want to be very explicit, so we can cover new media streams that
> have obvious meaning when we apply the tags without requiring every new m=
> to have text saying how this spec applies.
>
> Brian
>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 18 Aug 2016 11:30:32 +0200

Den 2016-08-18 kl. 07:29, skrev Bernard Aboba:
>
> Addition of some text on screen sharing seems like a good idea. There 
> are differences between screen sharing/remote control implemented with 
> m=application (e.g. RDP screen sharing) and WebRTC screen sharing, 
> which is handled with m=video.
>
> a=sendonly advertising the ability to send English (the screen share) 
> and another m=video line with a=sendrecv (generated by a webcam), 
> advertising the ability to send and receive ASL. It may not be obvious 
> from the SDP that one of the m=video lines is a screen share and even 
> if the  O/A exchange accepts the screen sharing m line (without both 
> sides even knowing what it is for), it might or might not be used.
>
It seems to me that you should register and use a value for RFC 4796, 
the sdp Content Attribute for shared screen.
The task for the humintlang attributes is to be a tool for negotiating 
the main conversational languages and modalities. So, if you do not have 
the intention to use the shared screen for the main dialogue it should 
not have the humintlang attribute.

This could be an application where you use the lang attribute for the 
shared screen, if you just want to describe what languages are available 
on that shared screen. But the current RFC 4566 information on the Lang 
attribute also talks about default language for the session, so we 
should spend some efforts on describing in the humintlang draft how an 
sdp with mixed lang and humintlang attributes shall be interpreted.

I can imagine applications where a shared screen can be used for the 
main dialogue. It could be for communication with persons with cognitive 
disabilities, when you exchange semi-stndardised pictograms. There are 
apps for that purpose, but a shared screen could be a rapid way to get 
some communication going when a need suddenly appears. But I think it 
takes us too far if we include that in the humintlang draft now.

/Gunnar
>
> On Aug 17, 2016 6:55 AM, "Brian Rosen" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I wouldn’t want to assume anything about future modalities, but
>     maybe we could say something along the lines of “Application of
>     the humintlang tags to SDP sections where human understandable
>     media in specific languages is sent, such as m=application (e.g.
>     WebRTC text media) or m=message (MSRP) is permitted”.  That might
>     even cover something like a screen share where you might have
>     slides in multiple media available.
>
>     I don’t want to be very explicit, so we can cover new media
>     streams that have obvious meaning when we apply the tags without
>     requiring every new m= to have text saying how this spec applies.
>
>     Brian
>
>     > On Aug 17, 2016, at 9:42 AM, slim issue tracker
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > [email-masked] <mailto:[email-masked]>
>           | [email-masked]
>     <mailto:[email-masked]>
>     > Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/21
>     <https://trac.tools.ietf.org/wg/slim/trac/ticket/21>>
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/slim>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/slim>
>
>
>

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