Re: [Widex] Review of Requirements document
Dean Willis <dean.willis@softarmor.com> Mon, 18 September 2006 19:13 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOYP-0004oC-9B; Mon, 18 Sep 2006 15:13:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPOYN-0004nn-OZ for widex@ietf.org; Mon, 18 Sep 2006 15:13:15 -0400
Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPOYL-0002mY-8n for widex@ietf.org; Mon, 18 Sep 2006 15:13:15 -0400
Received: from [64.101.149.162] ([64.101.149.162]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k8IIFwDE023877 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 18 Sep 2006 13:16:00 -0500
In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268B027DEA61@trebe101.NOE.Nokia.com>
References: <1C1F3D15859526459B4DD0A7A9B2268B027DEA61@trebe101.NOE.Nokia.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <77D30015-71EA-4221-BA18-B8ECB7D1A1A3@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Widex] Review of Requirements document
Date: Mon, 18 Sep 2006 14:13:09 -0500
To: widex@ietf.org
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
Cc: "Vlad.Stirbu@nokia.com> <Vlad.Stirbu@nokia.com" <Vlad.Stirbu@nokia.com>
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>, <mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>, <mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org
It seems to me that the commentary from Lisa indicates a few things that should be touched up before requesting Apps-area expert review on the document, which I would like to do either before or in conjunction with working-group last call. With a document of this sort and the small community that we have working on it, I think it is important to get some external review so that we can discover whether the level of exposition is adequate for a new reader. What do you folks think of revving this document fairly quickly to accommodate the suggestions below, then starting area and working group final reviews? -- Dean Willis, as chair On Sep 7, 2006, at 10:48 AM, <Vlad.Stirbu@nokia.com> <Vlad.Stirbu@nokia.com> wrote: > Hi Lisa, > >> -----Original Message----- >> From: ext Lisa Dusseault [mailto:lisa@osafoundation.org] >> Sent: 21 July, 2006 22:29 >> To: widex@ietf.org >> Subject: [Widex] Review of Requirements document >> >> >> This review comes from me as an individual. These are >> questions and suggestions for improving the document (not >> requirements from your advising AD), and it may well be that I >> don't understand the problem space well enough yet. >> >> 4. Scenarios >> >> I am not sure why the NAT traversal and IPv4/IPv6 stuff is in >> this document in so much detail. Does it require this much >> explanation and diagrams? What requirements follow from these >> scenarios? > > The relation might not be so obvious but, as Widex will define both a > framework and a message exchange used for synchronization (e.g. WOs), > implementers needs to be aware of the network environment challenges > when they will choose the service discovery and session setup > mechanism > and the transport protocol that is most appropriate for their > particular > target environment. We might have gone too deep into details in this > document and a better place for those should have been the framework > document but they are quite important to understand the problem. > >> >> To a reader like me, a scenario that described an example use >> case justifying the "multiple modes of interaction" would be useful. > > Would it be enough if we point the reader instead to the W3C's > Multimodal Architecture which is one possible customer of the Widex > framework? > >> >> I think your scenarios are designed for a reader that >> understands the problem that's being solved but may not >> understand the networking challenges, whereas I'm a reader who >> understands the networking challenges more than I understand >> the problem being solved :) >> >> 5. Requirements >> >> 5.1: >> " o The framework MUST be modular, e.g. multiple session setup >> mechanisms may be used." >> >> Flexibility is good; interoperability is even better. How >> about adding something like: "There must be ONE >> mandatory-to-implement session setup mechanism" (you might >> also add desired characteristics for the mandatory mech.) > > The Widex framework can be used in different environments and those > can > have characteristics that differentiate them quite a lot and these > characteristics were taken into account by the developers of the > service > discovery and session setup protocols. For example, in an unmanaged > network like those typically found in home networks, an implementer > may > choose between Rendezvous/Bonjour and UPnP. In other environments, > where > SIP infrastructure is available, implementers can use it. Other > alternatives include SLP or SRV records or it might be possible > that in > some close environments there is no need for service discovery and > session setup at all if you have means to manually input the URL of > the > server in the client. > > It would be great if a mandatory mechanism will be defined but it > seems > that we don't have any mechanisms that is universally applicable. For > this reason, in order to help interoperability and to provide a > somehow > unified experience regardless of what is the actual service discovery > and session setup mechanism, the framework has some requirements on > what > the mechanism must and should negotiate (they are listed in the > framework draft). > >> >> 5.2: >> " o The service discovery mechanism MUST be able to discover both >> Widex Renderers and Widex Servers." >> >> At a minimum, there are Security Considerations implications >> from this, particularly w.r.t. privacy of renderers. I would >> like to understand better the reasoning behind the requirement >> for discoverability of Widex renderers. > > A TV set or a smart screen can play very well the role of Widex > renderer > and it might be useful if you could use this as a secondary > display. Of > course, privacy of the renderers is very important and implementers > should balance what capabilities should be revealed and which > should be > kept private. For example, somebody can choose not to reveal anything > about the renderer besides that it is a Widex renderer but that will > have quite negative impact as the server will not be able to > provide the > UI that best suits the renderer capabilities, instead providing the > default UI. > > Privacy concerns are valid also for the Widex servers which might host > sensitive applications and you want to allow only specific > users/renderers to interact with. Fortunately, these issues were taken > into account by the designers of service discovery and session setup > mechanisms. > >> >> 5.3: >> " o The WOs MUST contain only information having remote scope." >> >> I just don't understand this requirement. > > The meaning of WOs was defined in section 3.3. and specifically refers > to the WOs.Event. Do you think that we need to be more specific about > which WOs this requirement is about? We need to think that while > developing the framework document we detected that we need more WOs > than > initially envisioned in this document (e.g. WO.Selector) and the > requirement should cover also those ones. > >> >> 5.3: >> " o The WOs MAY support multiple modes of interaction, and it >> is the >> responsibility of the application to synchronise modalities and >> not that of the Widex protocol." >> >> I believe this implies that multiple modes would indicate >> multiple Widex protocol sessions. Is that correct? It might >> be good to state the implication. > > Yes, this implication in correct. > >> >> Thanks, >> Lisa >> > > > > Thanks, > Vlad > > _______________________________________________ > Widex mailing list > Widex@ietf.org > https://www1.ietf.org/mailman/listinfo/widex > _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex
- RE: [Widex] Review of Requirements document Vlad.Stirbu
- Re: [Widex] Review of Requirements document Dean Willis
- Re: [Widex] Review of Requirements document Lisa Dusseault