On 2013-01-26 09:53, Harald Alvestrand wrote:
> On 01/25/2013 10:51 PM, Gunnar Hellstrom wrote:
>> On 2013-01-18 17:06, Magnus Westerlund wrote:
>>> WG,
>>>
>>> I would here by like to announce a two week WG last call that ends on
>>> the 1st of February.
>>>
>>> Document is available here:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ 
>>>
>>>
>>
>> We had a good discussion in December on inclusion of the real-time 
>> text medium.
>>
>> It was decided to document three alternative implementations with 
>> pros and cons and after that decide which one to standardize together 
>> with the two already mentioned media in rtcweb.
>>
>> The three alternatives were:
>> 1.) An RTP medium similar to audio and video, using RFC 4103 transport.
>>
>> 2.) A semi-reliable data channel with a standardized label.
>>
>> 3.) A web service based protocol, such as BOSH and XEP-0301 for 
>> real-time text in XMPP with a well specified integration with rtcweb 
>> in a common application.
>>
>> For all three cases, there is a need to have a specification for how 
>> calls with audio, video and real-time text are exchanged with SIP 
>> based environments, e.g. for interaction with RFC 6443 based 
>> emergency services.
>>
>> Text is a natural part of today's video and audio applications, so 
>> all use cases look quite meager without it.
>>
>>  I suggest that we make a rapid mini-investigation on the real-time 
>> text alternatives and decide which variant to include in a use case.
>
> I disagree with this summary on two points:
>
> - I think it's broken to choose between implementation strategies in 
> an use case. The use case needs to specify the function that we want 
> to achieve.
Yes, I totally agree, I did not mean to have the discussion on solution 
in the use case document.
>
>
> - I don't recall a declaration by the chairs that text would be 
> included in the use cases for RTCWEB.
I repeat my proposal to do so. This time with a shortened, generally 
expressed use case that is intended to allows any one of the three 
implementation alternatives to be selected.
>
>
> My memory is flaky, so if you can find the declaration by the chairs, 
> I'm happy to let the last point pass.
>
Yes, I am on my way to do the last point as well. But timing requires 
the addition to the use cases to be handled now.


Thus: Proposal for adding real-time text to the use cases, adjusted to 
be general and minimal:

--------------------------Add real-time text in a general way in use 
case draft-------------------------------------------

4.2.15.Simple Total Conversation service

4.2.15.1.Description

  

    This use-case has the audio and video communication of the Simple

    Video Communication Service use-case (Section 4.2.1  <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.1>).

  

    In addition to this, the users can send and receive real-time text
    in the same call.  While one user types in the real-time text area, it

     is nearly immediately presented to the other user.

    By providing these three media together, the Total Conversation
    service is provided.

    Interworking with SIP calls with the same media set, and with SIP
    based emergency services is also in scope of this use case.

  

4.2.15.2  <#section-4.3.1.2>.   Derived Requirements

  

    F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,

  

    F39,F40, F41

  

    A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27

  

..............

    F39              The browser MUST be able to handle text entry

                    via applications to generate real-time
                    text streams to be included in Total Conversation
                    calls. Real-time text and Total Conversation
                    Services are defined in ITU-T F.700 and F.703.

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

    F40               The browser MUST be able to send real-time text

                    streams to a peer.

  

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

    F41               The browser MUST be able to receive, process and

                      convey real-time text streams from peers to
                     applications.

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

    

  

.....

    A27              The Web API MUST provide a mechanisms for  
                    handling real-time text among the streams.  
  ----------------------------------------------------------------



/Gunnar