Web Real-Time Communication Use Cases and Requirements
RFC 7478

Note: This ballot was opened for revision 14 and is now closed.

(Richard Barnes) Yes

(Jari Arkko) (was Discuss) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2014-05-14 for -15)
No email
send info
- References please

   Assuming that ICE will be used, this means that the service provider
   would like to be able to provide several STUN and TURN servers (via
   the app) to the browser; selection of which one(s) to use is part of
   the ICE processing.

-  But in addition to this, the users can send and receive files stored
   in the file system of the device used.

3.3.9.2. Additional Requirements

   ----------------------------------------------------------------
   REQ-ID      DESCRIPTION
   ----------------------------------------------------------------
   F35     The browser must be able to send reliable
           data traffic to a peer browser.
   ----------------------------------------------------------------

Do you want to say?

 F35     The browser must be able to send files to a peer browser.

Does "data traffic" = file?
Also, reliability is implicit, not?

-
particiapants  -> participants

- section 3.3.11. Multiparty video communication,  3.3.12, and potentially so other: Any connection with "Use Cases for Telepresence Multistreams", RFC 7205?

- Why are the API requirements in an appendix?
Because there are not normative? If so, make it clear.

Alissa Cooper (was Discuss) No Objection

Comment (2014-05-14 for -14)
No email
send info
Thanks for addressing my DISCUSS.

The requirements listed in 3.3.7.2 are incorrect. First, F17 does not derive from the use case described in 3.3.7.1. Second, the text listed for F22 is not the appropriate text. To be consistent with how F22 is used in the rest of the document, it should say:

"The browser should be able to take advantage
           of available capabilities (supplied by network
           nodes) to prioritize voice, video and data
           appropriately."

(Spencer Dawkins) No Objection

Comment (2014-05-13 for -14)
No email
send info
Thank you for addressing Alissa's DISCUSS, and I agree with the proposed text.

I noticed a couple of things other ADs didn't comment on yet:

3.3.12.1.  Description

   Note: the difference regarding local audio processing compared to the
   "Multiparty video communication" use-case is that other sound objects
   than the streams must be possible to be included in the
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   spatialization and mixing.  "Other sound objects" could for example
   be a file with the sound of the tank; that file could be stored
   locally or remotely.

This is really rough. Perhaps "other sound objects must be allowed to be included with the audio streams in spatialization and mixing"?

In these requirements:

   ----------------------------------------------------------------
   Requirements related to audio processing
   ----------------------------------------------------------------
   REQ-ID      DESCRIPTION
   ----------------------------------------------------------------
   F27     The browser must be able to apply spatialization
           effects when playing audio streams.
   ----------------------------------------------------------------
   F28     The browser must be able to measure the
           voice activity level in audio streams.
   ----------------------------------------------------------------
   F29     The browser must be able to change the
           voice activity level in audio streams.
   ----------------------------------------------------------------
   F30     The browser must be able to process and mix
           sound objects (media that is retrieved from
           another source than the established media
           stream(s) with the peer(s) with audio streams.
   ----------------------------------------------------------------

F27 says "when playing". The other requirements don't. Is it obvious to everyone but me whether F28 and F29 apply to a browser sending audio, a browser receiving audio, or both?

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-01-23)
No email
send info
Thanks for addressing my discuss points (and sorry
it took so long)

Didn't check these.

- intro: I don't get how the document is planned to be
used later, but that's ok. For now however, I'm reading
the requirements as if those are the ones that the WG
are working to, since I've no other sensible choice
really. (And the plan confuses me more if W3C are
taking these as real but rtcweb isn't.)

- F10: heh, which video codec exactly? :-) 

- F11: Is 2804 the exactly right reference, maybe 7258
is worth adding (now its published) as that also
envisages non-targetted PM whereas 2804 is really only
considering targetted wiretap. Or maybe refer to both. 

- F19: Is acquiring call metadata via TURN considered a
breach of F11? If not, then shouldn't that also get a
mention somewhere?

- F35: the title of 3.3.9 is about files but the
requirement is about data, seems like a mismatch

- 3.3.10: I've heard this use-case before. It was
outlandish then. Not objecting though.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-05-08 for -14)
No email
send info
The change log says that this was done in -11:

   o  Removed the "Conventions" section with the key-words and reference
      to RFC2119.  Also changed uppercase MUST's/SHOULD's to lowercase.

But some of it was reverted: the "Conventions" section and the 2119 reference re-appeared in -12, and remain there in -14.

(Kathleen Moriarty) No Objection

Comment (2014-05-13 for -14)
No email
send info
I support Alissa's discuss and appreciate you addressing her security concerns.

In Section 6.2, can you repeat the requirement to prevent wiretapping in this list?  Other security requirements are repeated and this one if important in light of the revelation on GHCQ gaining access to Yahoo web chat a couple of months ago.

(Martin Stiemerling) No Objection

(Pete Resnick) Abstain

Comment (2014-05-14 for -14)
No email
send info
This document is a mishmash of UI requirements, local browser implementation requirements, and protocol requirements, with no distinctions being made among them. Given the IETF's notorious lack of skill in producing good UI work, and a great deal of text over the years indicating that we don't do UI and we don't constrain local implementation choices when they don't affect interoperability, I'm very dubious about the worth of this document. Then the introductions says:

   This document was developed in an initial phase of the work with
   rather minor updates at later stages.  It has not really served as a
   tool in deciding features or scope for the WGs efforts so far.  It is
   proposed to be used in a later phase to evaluate the protocols and
   solutions developed by the WG.

So the document was not found to be of use on input to the WG, and it's not clear to me what exactly happens if the evaluation concludes that the protocols and solutions don't meet these requirements at the end.

I don't see the point in publishing this document, certainly at this time.

Moreover, there are things in this document which strike me as problematic. I suspect things like those said in 3.3.1.1 will end up being (inappropriately) used as a bludgeon later, for no good reason: "Well, the requirements document published by the IETF says that you have to have a self-view during session establishment. You don't have self-view during session establishment. You're non-conformant and therefore will not be allowed in the market." Even mentioning self-view during session establishment in an IETF document gives me the creeps; I can imagine UIs with the feature, and I can imagine them without.

Some of the requirements seem awfully suspicious. For example:

   F13     The browser must encrypt, authenticate and
           integrity protect media and data on a
           per-packet basis, and must drop incoming media
           and data packets that fail the per-packet
           integrity check.  In addition, the browser
           must support a mechanism for cryptographically
           binding media and data security keys to the
           user identity (see R-ID-BINDING in [RFC5479]).

Maybe "per-packet encryption" means something magical, but can't we imagine a protocol decision that ends us up with stream-based or body-based encryption that is not "per-packet" that would still be perfectly reasonable? I wonder whether this document is over-constraining.

And finally, we have stuff like this:

"3.3.10.  Hockey Game Viewer"
"3.4.2.  Fedex Call"

Cute, but seriously? Do we really need cultural references like this?

I can't support the publication of this document. I won't stand in the way if it has consensus behind it, but I don't see the point.