[wbs] Johan Hjelm response to 'Device Description Technologies Survey'

Here are the answers submitted to 'Device Description Technologies Survey'
(the public) for Johan Hjelm.



---------------------------------
Name of device description technology or device description product
----


Answer: 
IETF SDP and SDP NG (MMUSIC WG)




---------------------------------
Status of technology 
----
For example, indicate whether the technology is an open standard, a
reference implementation or a proprietary technology.

Answer: 
Open standard (SDP is RFC 2327)




---------------------------------
Context of the technology 
----
Is the technology or product used for content adaptation? If not, what is
its purpose? What is the target audience? Is it a standalone technology,
or is it part of another product or platform?

Answer: 
Multimedia communications protocols use a common platform to express
media and session descriptions: the Session Description Protocol, SDP.
The many uses of SDP have led to (requests for) numerous extensions
and have led to recognition of several flaws in the protocol design.
In spite of these, it is widely deployed.

(from http://www.ietf.org/html.charters/mmusic-charter.html)




---------------------------------
What markup languages does your product support? 
----




 * [ ] WML 1.x (WML)
 * [ ] WML 2.x (XHTML-MP)
 * [ ] iMode/cHTML
 * [ ] HTML (3.2 up)
 * [ ] XHTML
 * [x] VoiceXml
 * [x] Other W3C Markup (e.g. SVG, SMIL) (Fill the text area below)
 * [ ] Other non-W3C Markup (Newsml, ...) (Fill the text area below)
 * [ ] Proprietary content (Fill the text area below)

 
SMIL, MPEG, etc - in principle, anything which can be transferred using a
session. 




---------------------------------
What are input and output features supported by your product ?
----
Input



 * [x] Touch screen (phone, PDA, "full" size)
 * [x] Limited keys
 * [x] Joystick/mouse (continuous pointer) 
 * [x] Full keyboard (on-screen, detachable, permanent)
 * [x] Voice
 * [x] Other (gravity sensor, barcode, etc - please explain) (Fill the
text area below)

 
There are no constraints as such.




Output



 * [x] Text screen
 * [x] Graphic screen (tiny, small, medium, large)
 * [x] Multi screens
 * [x] "heads-up screen"
 * [x] Voice
 * [x] Other (Fill the text area below)

 
There are no constraints as such.




---------------------------------
Description 
----
If you can, please provide a brief architectural overview of the
technology or product.

Answer: 
>From the group homepage:
http://www.ietf.org/html.charters/mmusic-charter.html

"Various extensions to SDP will be pursued to remedy the most
urgent of SDP's shortcomings. These will be limited to use of
SDP in conjunction with connection-oriented media such as TCP
and SCTP, offering support to work with NATs and firewalls
(e.g. via the ICE methodology), and exchange of media session
security keys.

With the exception of these specific items, only extensions within
the existing SDP framework will be done (e.g. registering new codecs
and defining parameters for them extending SDP to include new address
families).

To address the more fundamental issues with SDP, a next generation of
SDP, referred to as SDPng, will be needed. An initial proposal is now
available, and will be progressed to Experimental RFC while we gain
experience with implementations. An informational document will be
produced describing how the transition to a new session description
protocol can be managed, to prepare implementors for such a future
change.

MMUSIC will maintain and revise the specification of the Real Time
Streaming Protocol (RTSP), including fixes and clarifications based
on implementation experience. The revised RTSP specification will be
re-issued as a Proposed Standard RFC. We will also document how RTSP
can be used in the presence of NAT boxes.

An Internet Media Guide (IMG) is a collection of multimedia session
descriptions expressed using SDP or some other session description
format. It is used to describe a collection of multimedia sessions
(e.g. television programme schedules). The IMG must be delivered to
a potentially large audience, who use it to join a subset of the
sessions described, and who may need to be notified of changes to the
IMG.

MMUSIC will investigate delivery mechanisms for IMGs, generalizing
our work on session announcement and discovery protocols (SAP, RTSP,
SIP). We will investigate and document requirements for IMG delivery
mechanisms, and identify the requirements that these delivery
mechanisms impose on the session description formats used by the IMG.
We will then work to produce a framework document outlining the use
of (existing) protocols to create an IMG delivery infrastructure.
After successful completion of these initial milestones for IMG
delivery, the MMUSIC working group will decide whether or not MMUSIC
is the proper place to pursue any needed mechanisms for IMGs, and if
so, recharter accordingly

The MMUSIC work items will be pursued in close coordination with other
IETF WGs related to multimedia conferencing and IP telephony (AVT, SIP,
SIPPING, SIMPLE, XCON, MEGACO and, where appropriate, MIDCOM and NSIS).
Where appropriate, new separate working groups may be split off (as has
happened with the SIP WG).

The Working Group is also charged with addressing security issues
related to the protocols it develops."

Note that SDP has been submitted to the IESG as a Proposed Standard. 




---------------------------------
Reliance or usage of existing standards 
----
Please indicate how the device-description part of your technology or
product builds (or relies upon) existing standards. For example: HTTP,
XML, CC/PP, etc

Answer: 
SDP is deployed in most, if not all, SIP clients. This implies a pretty
wide usage. 




---------------------------------
Does the technology specify, or provide, a repository (or repositories)
for the storage of the device descriptions?
----
if you answer "yes", provide the following details:

         * a brief description of the data structure
        e.g. flat files, RDMBS, OODMS, hierarchical data structures
         * To what level of abstraction does the repository store the
data?
        e.g. per model, per operator, per browser etc
         * How does the technology manage multiple revisions of the same
device?
        (e.g. inheritance, fallback, etc)
         * How does the technology manage attributes or properties for
unknown devices?
        (i.e. those not yet stored or those not recognised)

         * In
your experience, how many discrete device descriptions do you believe
are essential to produce satisfactory content adaptation worldwide? 
            - < 10
            - 10 - 50
            - 50 - 100
            - 100 - 200
            - > 200

      



 * ( ) Yes
 * (x) No

Comments (or a URI pointing to your comments): 
SDP and SDP-NG does not in themselves provide for a repository




---------------------------------
Vocabulary
----
Does the technology specify an explicit vocabulary of device attributes?
if you answer "yes", please provide the following details:


         * a brief description of the vocabulary
        Is it extensible, typed, based on standard vocabularies, and so on
         * Which areas of a device's capabilities does it cover?
        These might include browser behaviour, markup compliance, physical
characteristics, messaging clients, radio behaviour etc
         * In your experience, how many device attributes do you believe
are essential to produce satisfactory content adaptation?
          
        
            - < 10
            - 10 - 20
            - 20 - 50
            - > 50

      


 * (x) Yes
 * ( ) No

Comments (or a URI pointing to your comments): 
The SDP vocabulary is fairly simplistic, consisting of types and values.
It is based on standard vocabularies. Typically, less than 10 attributes
are required to provide a satisfactory media experience.

SDP-NG provides a much richer vocabulary. 




---------------------------------
Does the technology specify, or provide, a process or mechanism  for the
capture of attributes for a specific device?
----
If you answer "yes", please provide a brief description of the profiling
process. 
Is it structured or ad-hoc, empirical (using a real device) or
theoretical? Does it require a human to test the actual device? An active
network connection?
      


 * ( ) Yes
 * (x) No

Comments (or a URI pointing to your comments): 





---------------------------------
Does the technology specify, or provide, a technique for querying a
repository to extract device descriptions?
----
If you answer "yes", please provide the following details : 

         * a brief description of the query process
        e.g. DB queries, SPARQL, data is keyed or indexed
         * How can the technology export or provide device descriptions
for the purposes of content adaptation?
        e.g. standalone XML files, text configuration files
         * Do you provide APIs for applications to access the data? Which?
        e.g. Java, PHP, .NET
      


 * ( ) Yes
 * (x) No

Comments (or a URI pointing to your comments): 





---------------------------------
Do you believe that the essential device information should be publicly
available?
----




 * (x) Yes
 * ( ) No
 * ( ) No Opinion

 
This is the opinion of Ericsson. It does not necessarily reflect the
opinion of other users of the standard, nor that of Ericsson in particular
deployments of systems based on SIP. 


These answers were last modified on 30 September 2005 at 07:49:58 E.S.T.
by Johan Hjelm

Answers to this questionnaire can be set and changed at
http://www.w3.org/2002/09/wbs/1/ddwgld/ until 2005-09-30.

 Regards,

 The Automatic WBS Mailer

Received on Friday, 30 September 2005 07:55:12 UTC