Good point Harald regarding F.700 A.3.2.3 calling up "font support for *all
characters* in ISO-10646-1".

I suspect that the reference to F.700 was to the service and performance
requirements of a range of multimedia services. I am not aware of another
'more suitable' set of Service Requirements document that we can reference.
F.700 (and F.703) are frequently referenced - but some people probably
quietly ignore the full implications of A.3.2.3.

So we need to capture the 'general service requirements' but remove any
parts of F.700 (or F.703) that are not applicable.

As the proposed additional use-case just adds RTT to the video+audio, I
suggest that we just add the (selected) RTT Requirements that suit rtcweb
to the use-case and maybe put an informational note to F.700 and F.703.

Cheers,
/Barry Dingle



On Fri, Feb 1, 2013 at 10:07 AM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  FWIW, I strongly object to a couple of formalities here:
>
> - I object to making normative reference to F.700 and F.703.
> - I object to requiring interworking with emergency services.
>
> If there's strong support in the WG for including the use case, I'm
> willing to go along with that.
>
> (The reason for not wanting to normatively reference F.700 and F.703 is
> that they're very large balls of string, and I have no idea where the
> string may lead; for instance, the definition of "Total Conversation" in
> section A.3.2.3 of F.700 requires font support for all characters in
> ISO-10646-1; I doubt somewhat that the person who wrote that paragraph has
> studied the task of providing such font support - I found that particular
> linkage in a few minutes of scanning the docs.)
>
>
> On 01/30/2013 10:15 PM, Gunnar Hellstrom wrote:
>
> 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.  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.****
>  ----------------------------------------------------------------****
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>