[M4IF Technotes] DMIF and uuData

[Art Yerkes]

Hello all,
We have implemented a DMIF instance (apart from any comittee sources)
that we believe is commercially viable.  It's a C API that uses an XML
configuration.  The DMIF specification makes it possible to write such
an API enabling applications to stream MPEG-4 without knowing about
transports or protocols.  It has gone well.  We have written some
sample code with it, and it fully complies with DMIF.  The development
of DMIF represents significant change in the design of media
infrstructure when it becomes mainstream, because it allows a
beautiful sharing of code between applications.  I am confident that,
IP issues aside, DMIF will become the preeminent API for writing
streaming apps, because it provides an amicable divorce between code
that implements transport and code that implements the 'value',
presentation, player, IPMP, and other code.
However, I noticed one thing that makes DMIF more complicated to
adhere to if you don't know what application your DMIF instance will
be communicating with.  In our case, our DMIF is meant to be sold as a
component.  Perhaps no-one else plans to do this, but we wanted to
mention our problem in hopes that someone else may benefit from
sharing experience about this matter.  I propose a problem and one
possible solution.  I am interested in hearing comments both about our
view of this problem and our intended solution.
The problem as I see it is that uuData in it's many forms throughout
the specification of the DMIF Application interface is only opaque
data.  Even though this data is meant for interpretation by the
application and not by DMIF, conforming applications eventually need
to settle on a form for this data both to prevent misinterpretation by
incompatible DMIF applications which implement the same protocol, and
to facilitate good communication between DMIF applications that are
meant to be compatible.  I have several reasons for thinking this:
1) A vendor may wish to implement a DMIF service layer (part of a
"peer application," running on the same computer that reads a certain
filetype and delivers data to the DAI layer of the calling
application. The generaic service provider needs a way to interface
with potentially many Originating DMIF peer applications.
2) In 14496-6.10.4.1, it is specified that the DMIF user 'might'
provide additional information such as client credentials in uuData.
A media-unaware transport agent (such as a firewall tunnel or similar)
may need to check credentials before admission to the firewalled
environment.  This necessitates an application independent method at
least for credentials signalling.  In HTTP and RTSP, this is handled
with a WWW-Authenticate response-header, which allows any HTTP-enabled
application to interact in a seamless manner with different
authentication systems of which it is aware.  This does not limit
application freedom very much.  Vendors still have the opportunity to
use any available authentication mechanism (nothing is specified about
what mechanism to use), it simply allows the mechanism and it's
associated data to be clearly identified.
3) In 14496-6.10.4.5, the uuDataIn field provides information about
the channels requested.  This information is important when individual
elementary streams contain different parts of a presentation.  An
example of this would be a presentation containing several JFIF images
connected by hyperlinks, such as the menu system for a kiosk.
Although this information is "opaque to the delivery layer", it is not
opaque to the remote DMIF application.  Again, an identification of
what data has been sent should also be sent in a standard form,
probably a MIME type preceeding the data.  Again, This is not too much
to ask, and provides the benefit of letting the peer DMIF application
know what to expect.  Even better would be the specification of a
requested ES_ID form and position.  This would allow (for example) a
disk DMIF instance to correctly identify a requested elementary stream
in a uniform way.  It would also allow two DMIF peers made by
different companies to dicuss a specific elementary stream, even if
they were not 'born' compatible.
4) In 14496-6.10.4.6, the specification states that the ES_ID may be
present in the return uuData.  It's presence and form (2 bytes,
network byte order?) should be specified, as well as where it can be
found in the uuData should be specified.  This makes it possible for
an application to silently ignore most of the opaque data that it
doesn't understand, but still retrieve the ES_ID.
5) In 14496-6.10.4.9, as with the other uuData fields, this one
carries no indication of it's contents.  The problem here is that both
a local DMIF scenario, and a remote instance have need of the
information contained therein.  This field has been implemented as
four-byte little endian integers and as text strings.  It would be
nice to get an indication of the control scheme in use.  An 'integer'
scheme would not be pleased to get the string 'PLAY\0' and likewise, a
DMIF peer implemented to expect null terminated strings would be
imperiled by the reception of '\010TEARDOWN' (a string with the length
information in front).
While one might envision several solutions, I would propose that uuData
objects follow HTTP style rules:
At least a 'Content-Type: ...' header must be present before any data,
but any number of response headers are allowed.  Response headers are
terminated by a blank line.  Any data, binary, ASCII, opaque or
otherwise may follow.  The Content-Length header is never needed in
this scenario because the length of the object is specified in the
DMIF primitive itself.  The payload part of the Content-Type header
should be a textural MIME type.
I also propose that the HTTP style WWW-Authenticate scheme be used in
the ServiceAttach and ServiceDetach (when attachment is denied).
I further propose that ES_ID, when present, shall be sent among the
headers as mpeg4-esid, or mpeg4-esids if there are multiples (as
sugguested in the draft-singer-mpeg4-ip-02 IETF draft.
I wanted to gather comments and see if anyone else is like minded.
Perhaps, this type of discussion can be the basis for either a formal
or informal rule with regard to those pesky opaque bytes.
References
Title: A Framework for the delivery of MPEG-4 over IP-based Protocols
Authors: D. Singer, Y Lim
URL:
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-singer-mpeg4-ip-02.txt
Title: Real Time Streaming Protocol
Authors: H. Schulzrinne
URL: http://www.freesoft.org/CIE/RFC/Orig/rfc2326.txt
Title: Hypertext Transfer Protocol
Authors: R. Fielding, J. Gettys, J Mogul, H. Frystyk, L. Masinter, P. Leach,
T. Berners-Lee
URL: http://www.freesoft.org/CIE/RFC/Orig/rfc2616.txt
Art Yerkes
Chief Software Architect
GMV Network
-- 
HTTP_TRACE( "RTSPSession has died of snarfage.\n" )
-- Anonymous C source file
#define SS_USR      6        /* The user is broken           */
-- Anonymous Header File