Re: [Widex] Review of Requirements document

Lisa Dusseault <lisa@osafoundation.org> Tue, 19 September 2006 23:17 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPoq3-0007YT-7K; Tue, 19 Sep 2006 19:17:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GPoq2-0007YN-Cb for widex@ietf.org; Tue, 19 Sep 2006 19:17:14 -0400
Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GPopz-0005vo-P0 for widex@ietf.org; Tue, 19 Sep 2006 19:17:14 -0400
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3DC01142282; Tue, 19 Sep 2006 16:17:07 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25136-04; Tue, 19 Sep 2006 16:17:06 -0700 (PDT)
Received: from [192.168.2.2] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 51CE9142280; Tue, 19 Sep 2006 16:17:06 -0700 (PDT)
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: <2509F7FF-CFE3-4283-B415-B5F1FD84097A@osafoundation.org>
Content-Transfer-Encoding: 7bit
From: Lisa Dusseault <lisa@osafoundation.org>
Subject: Re: [Widex] Review of Requirements document
Date: Tue, 19 Sep 2006 16:17:03 -0700
To: Vlad.Stirbu@nokia.com
X-Mailer: Apple Mail (2.752.2)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: df9edf1223802dd4cf213867a3af6121
Cc: widex@ietf.org
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

Discussion continued below inline...

On Sep 7, 2006, at 8: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.

I'm still concerned about the risk of describing NATs, or suggested  
solutions to the problems NATs post, in a way that's incompatible  
with the many other documents the IETF has produced on the topic.  It  
feels odd to type that; I'm generally in favour of explanatory text  
to help implementors!  I guess I'm not suggesting simply taking out  
the text, unless you really can refer to some BEHAVE or transport  
area document.  At some point it would need to be tied, as you  
suggest, to helping implementors choose the appropriate WIDEX options  
for their environment.  I would support moving this to the framework  
document.

>
>>
>> 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?

Probably yes

>
>>
>> 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).

I was a little confused here by what a "session setup mechanism" is.   
Here's what I was thinking: TCP is expected to work all over the  
Internet, and there's one way to create a session in TCP.  If you  
want a fancier kind of setting, BEEP or XMPP could work anywhere TCP  
works, and each of those have one way of creating a session.  So I  
was thinking WIDEX would require support for one of those.

But if you're indeed talking about service discovery, then I agree  
there's not one standardized mechanism that's guaranteed to work  
everywhere and be useful for each case.  Not every WIDEX server will  
be able to create SRV records, for example.  Still, if service  
discovery is very important for WIDEX (it isn't in email and  
calendaring where users type in their server addresses) then there'll  
need to be a lot of thought about whether the existing mechanisms are  
sufficient or whether WIDEX needs to "raise the bar" in this area by  
demanding (or specifying ) more.

>
>>
>> 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.

You might want to explain the use case that illustrates or motivates  
the requirement, in the requirements doc.  (I don't think exhaustive  
use-casing is very successful in IETF but in this case I just didn't  
get it without an example)

>
> 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.

I read "WOs" as short for "Widex Objects".  I don't agree it implies  
Event as is.  There were other problem words -- "having scope" and  
which end "remote" is.

Would this be correct?  "  o  The Widex Objects MUST contain only  
information meaningful in context of the renderer."

>
>>
>> 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