Re: [Widex] Review of Requirements document
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Widex] Review of Requirements document


Discussion continued below inline...

On Sep 7, 2006, at 8:48 AM, <Vlad.Stirbu at nokia.com> <Vlad.Stirbu at nokia.com> wrote:

Hi Lisa,

-----Original Message-----
From: ext Lisa Dusseault [mailto:lisa at osafoundation.org]
Sent: 21 July, 2006 22:29
To: widex at 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/widex



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.