Subject: SDP URL Scheme

From: FUJIKAWA Kenji <[email-masked]>
Date: Fri, 07 Aug 1998 13:36:25 +0900

We are planning to define a SDP URL scheme.

Multimedia sessions are described such as:

  sdp://224.192.2.3:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0

  sdp://london-station.bbcc.com:ttl=16/sdp+test#m=audio+10000+RTP-AVP+0

Any comments are welcome.

Thank you.
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
              WWW http://camino.kuis.kyoto-u.ac.jp/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                             e-mail [email-masked]
                             e-mail [email-masked]

INTERNET DRAFT                                            FUJIKAWA Kenji
draft-fujikawa-sdp-url-01.txt                             KURIYA Shinobu
                                                        Kyoto University
                                                               July 1998

                             SDP URL Scheme

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.''

   To view the entire list of current Internet-Drafts, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   This document describes a format for an Session Description Protocol
   Uniform Resource Locator (SDP URL) which will allow Internet clients
   to have direct access to multimedia sessions.

1. Introduction

   SDP[1] is a format for describing information of multimedia sessions,
   and generally is conveyed by SAP (Session Announcement Protocol)[4].
   However, SDP is just a format for session description and is intended
   to use different transport protocols including SAP, E-mail and World
   Wide Web (WWW).

   An SDP file has to be saved in a WWW server for distributing SDP
   messages when utilizing WWW.  At first, Internet clients have access
   to a WWW server to get an HTML file that has the URL of the SDP file.

FUJIKAWA Kenji         Expires on January 6, 1999               [Page 1]


INTERNET DRAFT               SDP URL scheme                    July 1998

   Clients have to have another access to the server to get the SDP file
   to start a multimedia session.

   SDP URL scheme eliminates the second unnecessary access to a WWW
   server.  Since SDP URL is written directly on an HTML file, a session
   can be started only by access to the HTML file with SDP URL.  It is
   not necessary to get another access to the server.

   When a user clicks SDP URL in an HTML file, a WWW browser
   automatically launch applications for participation in the session.
   This is equal to selecting a session on an application such as sdr.

2. Description of the SDP Scheme

   The SDP URL scheme is basically the same format as that of the
   original SDP except for a few points.

   A whitespace is replaced by '+', a return by '&', and the characters
   reserved in RFC 1738[2] and a original '+' by ascii code described by
   %xx.  The term "RTP/AVP" which specifies a transport protocol is
   replaced by the "RTP-AVP".  The <type> of  'v', 'o' and 's' which
   cannot be omitted in the original SDP can be omitted.  If 'v' is
   omitted, then the SDP version of an SDP URL is regarded as 1.

   URL is generally written in the format:

       <scheme>://<address>:<port>/<url-path>

   SDP's connection information and session name correspond to <address>
   and <url-path> respectively.

   An SDP URL takes the form:

       sdp://[ <address> [:ttl=<ttl>] [:noa=<noa>] ] / [<sessionname>]
             [ #<type>=<value> *[&<type>=<value>] ]

   The <address> is the connection address that will be either a unicast
   IP address or a class-D IP multicast group address.  The <ttl> (time-
   to-live) defines the scope with which multicast packets sent in a
   session should be sent when the <address> is a multicast address.
   The <ttl> is ignored when the <address> is a unicast address.  The
   value of <ttl> takes 1 when the <ttl> is omitted.  The <noa> (number-
   of-addresses) is the number of multicast addresses contiguously
   allocated above the base address <address>.

   These can also be described as a connection information 'c' and the

FUJIKAWA Kenji         Expires on January 6, 1999               [Page 2]


INTERNET DRAFT               SDP URL scheme                    July 1998

   <sessionname> as a session name 's'.  The <type>, the <value> and
   their order follow [1].

3. Examples

   The followings are some example SDP URLs using the format defined
   above. A multimedia session is on a multicast address 224.192.2.3,
   the session name "sdp test", TTL 16 and port 10000 .  The media type
   is audio, profile AVP and payload type PCM.

       sdp://224.192.2.3:ttl=16/sdp+test
       #m=audio+10000+RTP-AVP+0

   This could also be written in

       sdp:///#s=sdp+test&c=IN+IP4+224.192.2.3%2f16&m=audio+10000+RTP-AVP+0

   The former description is preferable for look, suiting to the URL
   convention.

   Multicast addresses are registered in DNS in [3].  In this case, the
   URL is also written as:

       sdp://london-station.bbcc.com:ttl=16/sdp+test
       #m=audio+10000+RTP-AVP+0

   where ``london-station.bbcc.com'' is the domain name of the address
   224.192.2.3.

   Some services may use additional data.  The time that a session is
   active is specified.  Both audio and video are used.  All media
   applications are requested to be receive-only and the maximum
   framerate of video to be 10.

       sdp://london-station.bbcc.com:ttl=16/sdp+test
       #t=2873397496+2873404696&a=recvonly
       &m=audio+10000+RTP-AVP+0
       &m=video+9999+RTP-AVP+31&a=framerate:10

5. Considerations to Scope Rule

   It is asserted that announcements of multicast sessions made via WWW
   cause the mismatch between the scope where WWW is valid and the scope
   restricted by the multicast addresses. [1] However, Ohta shows that

FUJIKAWA Kenji         Expires on January 6, 1999               [Page 3]


INTERNET DRAFT               SDP URL scheme                    July 1998

   this is not a problem but the idea of scope has an essential problem.
   [3]

6. QoS Specifications

   The notation of RSVP parameters should be defined in [1] or in this
   draft for the purpose of specifying Quality of Services (QoS).

7. Proposed Syntax

   The proposed BNF syntax is encoded as specified in RFC 1738 [2].

       sdpurl          = "sdp://" [ connection ] "/" [ sessionname ]
                         ["#" parameter *["&" parameter ] ]

       connection      = address [ ":ttl=" ttl ][ ":noa=" noa ]
       address         = addressname | addressnumber
       addressname     = *[ domainlabel "." ] toplabel
       domainlabel     = alphadigit |
                         alphadigit *[ alphadigit | "-" ] alphadigit
       toplabel        = alpha | alpha *[ alphadigit | "-" ] alphadigit
       alphadigit      = alpha | digit
       addressnumber   = digits "." digits "." digits "." digits
       ttl             = digits
       noa             = digits
       digits          = 1*digit

       sessionname     = 1*uchar

       parameter       = type "=" value
       type            = alpha
       value           = 1*uchar [ ":" attributevalue]
       attributevalue  = 1*uchar

       alpha, digit and uchar are defined in RFC 1738.

References

[1]    M. Handley and V. Jacobson, "SDP: Session Description Protocol",
       RFC 2327, Nov 1997.

[2]    T. Berners-Lee, L. Masinter and M. Mccahill, "Uniform Resource
       Locators (URL)", RFC 1738, Dec 1994.

FUJIKAWA Kenji         Expires on January 6, 1999               [Page 4]


INTERNET DRAFT               SDP URL scheme                    July 1998

[3]    M. Ohta, J. Crowcroft, "Static Multicast", Internet Draft draft-
       ohta-static-multicast-00.txt (work in progress), March 1998.

[4]    M. Handley, "SAP: Session Announcement Protocol", Internet Draft
       draft-ietf-mmusic-sap-00.txt (work in progress), Nov 1996.

Security Considerations

   (to be written)

Appendix

A. Implementation

   Implementation of an SDP URL interpreter for Emacs/WWW is available
   at
   "http://www.lab1.kuis.kyoto-u.ac.jp/members/magician/sdp-url-0.1.tar.gz".

Authors' Address

   FUJIKAWA Kenji
   Graduate School of Informatics,
   Kyoto University
   Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-01, Japan
   Phone : +81 75-753-5387
   Email : [email-masked]

   KURIYA Shinobu
   Department of Information Science,
   Faculty of Engineering, Kyoto University
   Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-01, Japan
   Phone : +81 75-753-5387
   Email : [email-masked]

FUJIKAWA Kenji         Expires on January 6, 1999               [Page 5]

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Aug 1998 08:37:50 -0400

Seems like we have this discussion every 6 months or so. Why can't you
just use the existing, standardized "data" URL and be done with it? That
URL type was designed exactly for these types of mappings.

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Fri, 07 Aug 1998 22:37:26 +0900

From: Henning Schulzrinne <[email-masked]>
Subject: Re: SDP URL Scheme
Date: Fri, 07 Aug 1998 08:37:50 -0400

> Seems like we have this discussion every 6 months or so. 

In this ML?
I did not noticed that.

> Why can't you

I am not sure what do you mean by "data" URL.
Does "data" URL mean just SDP,
or is such a URL type defined?

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Aug 1998 21:12:16 -0400

> > Seems like we have this discussion every 6 months or so.

Might have been on rem-conf, but this at least the third or fourth time.

> or is such a URL type defined?

ftp://ietf.org/internet-drafts/draft-masinter-url-data-03.txt

or http://www13.w3.org/Addressing/schemes.html

with type 'application/sdp'.

Since the draft is dated May 18, 1997, I assume that it is in some kind
of pre-RFC state (as it would have expired long ago otherwise).

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 08 Aug 1998 21:24:00 -0400

> > Seems like we have this discussion every 6 months or so.

Might have been on rem-conf, but at least 3 or 4 times.

> or is such a URL type defined?

The data URL is defined in an I-D. See
http://www.cs.columbia.edu/~hgs/rtsp/related.html

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Sun, 09 Aug 1998 23:24:21 +0900

From: Henning Schulzrinne <[email-masked]>
Subject: Re: SDP URL Scheme
Date: Sat, 08 Aug 1998 21:12:16 -0400

> Might have been on rem-conf, but this at least the third or fourth time.

I see.

I think this topic should be discussed on this ML
according to the AVT charter and the MMUSIC charter.

> with type 'application/sdp'.

This is like employing

	<a href="data:application/ftp;base64,ZGVzdD1mdHAubWVkaWEua3lvdG8tdS5hYy5qcA0KZGlyPXB1Yi9SRkMNCmZpbGU9cmZjLWluZGV4LnR4dA0K">

instead of 

	<a href="ftp://ftp.media.kyoto-u.ac.jp/pub/RFC/rfc-index.txt">

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 09 Aug 1998 12:05:23 -0400

>         <a href="ftp://ftp.media.kyoto-u.ac.jp/pub/RFC/rfc-index.txt">

Wrong. base64 encoding is only required if the content to be conveyed is
binary (a gif). An SDP description like

      v=0
      o=user1 53655765 2353687637 IN IP4 128.3.4.5
      s=Mbone Audio
      i=Discussion of Mbone Engineering Issues
      e=[email-masked]
      c=IN IP4 224.2.0.1/127
      t=0 0
      m=audio 3456 RTP/AVP 0

would look something like

data:applications/sdp,v=0%OAo=user1%OA....

The nice thing about this is that this a generic mechanism which can
easily recycle the MIME tables in browsers. Indeed, if SDR were to
understand SDP file arguments (Mark: hint...), this can work today. If
you want to try it, go to http://www.cs.columbia.edu/~hgs/etc/data.html
after configuring your MIME type file to have an entry along the lines
of

application/sdp whatever_application_handles_sdp %s

Works in Netscape 4.0 and 4.5 and possibly other browsers. The page also
contains an IMG with a GIF as an embedded 'data' item. No magic needed.
-- 
Henning Schulzrinne   [email-masked]
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Mon, 10 Aug 1998 01:58:45 +0900

My original mail was splitted somehow
(maybe because of the line starting with a period).

> .
> Here, I'm defining the "application/ftp" type as:
> 
> 	dest=ftp.media.kyoto-u.ac.jp
> 	dir=pub/RFC
> 	file=rfc-index.txt
> .
> 
> Note that I'm not criticizing "data" URL or the SDP format.
> 

From: Henning Schulzrinne <[email-masked]>
Subject: Re: SDP URL Scheme
Date: Sun, 09 Aug 1998 12:05:23 -0400

> data:applications/sdp,v=0%OAo=user1%OA....

O.K.

Then, this is like 

  data:application/ftp,dest=ftp.media.kyoto-u.ac.jp%0Adir=...

> contains an IMG with a GIF as an embedded 'data' item. No magic needed.

Of course, this works.

We once wrote such an application by awk and 
set up ".mailcap" like that.
This mechanism works well in the envirionment
where "data" URL is not used, and also works well
with "data" URL.

But this usage is as bad as the ftp example.

Not "data:applications/sdp,v=0%0Ao=user1%0A...."
but "sdp:v=0%0Ao=user1%0A...." is acceptable.

However, our porposal is better, I believe.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 10 Aug 98 18:24:49 JST

Henning;

> Wrong.

Henning, you are wrong.

You should better define data URL encoding of URLs and be laughed at.

What is intended by data URL should be better implemented
at HTML level to let it have inline data with all the
HTTP layer headers.

> easily recycle the MIME tables in browsers.

That's another bad thing with data URL.

As data URL is useful only in HTML environment, it should recycle
HTTP file name extension for default data type, which may be overridden
by HTTP-like headers.

						Masataka Ohta

---

From: Mark Handley <[email-masked]>
Date: Mon, 10 Aug 1998 10:10:44 -0400

>Any comments are welcome.

Please don't do this.  This has come up every year or so since 1994,
and is still a bad idea.

A URL provides indirection that is useful - it means the referring
pages don't need to change when the session details change.  Embedding
the description in the URL loses this indirection - the equivalent of
embedding HTML in an URL!  It leads to completely unnecessary
inconsistencies.

Also your syntax seems somewhat broken, given that a single multimedia
session can use multiple multicast groups or even multiple unicast
source addresses.

Instead, just fetch the full session descritpion using HTTP and
MIME-type application/sdp and everything is just fine.

Cheers,
	Mark

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Tue, 11 Aug 1998 10:48:42 +0900

Mark;

From: Mark Handley <[email-masked]>
Subject: Re: SDP URL Scheme 
Date: Mon, 10 Aug 1998 10:10:44 -0400

> It leads to completely unnecessary

A user fetches a Web page every time starting a new session.
When the page is chashed,
a user have to reload the page.
But this is inevitable in Web.

I can't imagine the case where a SDP URL is inconvinient
campared to a SDP file.
Would you show me an expamle?

> session can use multiple multicast groups or even multiple unicast

Our syntax can do.
Please read our draft carefully.

> MIME-type application/sdp and everything is just fine.

Please consider what is URL for.
URL or URI locates or identifies resources,
and provides a user with the method to access resources.

In the case of joining a session,
not session description but session streams are resources.
Thus, the URL for a session should not locate the session 
description but should locate the session streams.
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
              WWW http://camino.kuis.kyoto-u.ac.jp/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                             e-mail [email-masked]
                             e-mail [email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Aug 1998 00:24:06 -0400 (EDT)

Kenji,

I think that Mark is right.  Defining an SDP URL is a stretch.  URL
are supposedly pointers to a value; you don't encode the actual value
inside the pointer.

On the other hand, defining an RTP URL could make sense.  There is a 
clear relation between the pointer (an address and a port) and the
value (a media stream).  The number of attributes is moderate.

-- 
Christian Huitema

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 Aug 98 13:20:07 JST

Mark;

> pages don't need to change when the session details change.

Of course.

As dynamic assignment of multicast addresseses is proven to be
completely unnecessary, it is not at all a problem that multicast
addresses are looked up through DNS with or without DnS dynamic
update.

> why  Embedding

Yes, I agree with you that data URL is completely unnecessary.

> session can use multiple multicast groups or even multiple unicast

It is a broken idea that a single multicast session use multiple
multicast groups.

Multiple unicast source addresses are perfectly OK.

> MIME-type application/sdp and everything is just fine.

If you think HTTP SDP is fine, SDP URL is more than fine.

						Masataka Ohta

---

From: FUJIKAWA Kenji <[email-masked]>
Date: Tue, 11 Aug 1998 14:14:12 +0900

Christian;

From: Christian Huitema <[email-masked]>
Subject: Re: SDP URL Scheme
Date: Tue, 11 Aug 1998 00:24:06 -0400 (EDT)

>
> I think that Mark is right. Defining an SDP URL is a stretch.  

> URL

You are absolutely right.

In this case, media data streams are values,
while the information described by SDP is a pointer.

As a result, 
URL "http://.../test.sdp" is a pointer to a pointer.

It should be noted that the information exept one
required for media applications such as vic and vat
can be written in a free format in a Web page.
For example, in a Web page, you can place the information 
on the host of the session, his/her e-mail address, 
the pupose of the session, and so on.

> On the other hand, defining an RTP URL could make sense.  

> There is a 

You are right too.

We investigated RTP URL too as others might have.
(You can see a vestige in
 draft-ohta-static-multicast-00.txt).
But we have selected SDP URL
since we'd like to handle multiple streams at the same time.

By the way, 
I don't necessarily insist on the URL name "sdp:".
What I really want is the URL that locates sessions.
We named our scheme "sdp:" 
just because we recycled the SDP syntax.
---------------------------------------------------------------
FUJIKAWA, Kenji @ Grad. Sch. of Informatics, Kyoto Univ., Japan
              WWW http://camino.kuis.kyoto-u.ac.jp/index-e.html
                        TEL +81 75-753-5387 FAX +81 75-751-0482
                             e-mail [email-masked]
                             e-mail [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 Aug 98 14:20:40 JST

Christian;

> value (a media stream).  The number of attributes is moderate.

If I remember it correctly, it was Mark who said RTP URL is
not a good idea becasue sessions may consists of multiple
protocols, not necessarily RTP ones.

> I think that Mark is right.

Maybe.

> URL
> are supposedly pointers to a value;

A URL is a pointer to resource.

> you don't encode the actual value
> inside the pointer.

Of course.

All we need is information to identify resource type and to locate
the resource.

For sessions, IP addresse, port, duration and encodings are essential
information.

I think most (if not all) extra information, such as that for human
friendlyness, which may be contained in original SDP, should be dropped
in SDP URLs.

							Masataka Ohta

---

From: Peter Parnes <[email-masked]>
Date: Tue, 11 Aug 1998 07:50:56 +0200

> It is a broken idea that a single multicast session use multiple

How about sessions using layered distribution schemes for audio or video? They 
need multiple mcast groups per session or do you see that as multiple sessions 
as well?

/P

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 Aug 98 15:46:52 JST

Peter;

> need multiple mcast groups per session

Good point.

But I remember that there was a proposal in RSVP WG to distinguish
layered flows in a session by consequtive port numbers.

The problem is, then, whether we should prevent unnecessary layers
forwarded with best effort or not.

> or do you see that as multiple sessions 
> as well?

Not necessarily.

The question to be asked first is "Is layered encoding meaningful?
Is it meaningful to spend 6Mbps to send two layers of 1.5Mbps and
6Mbps pictures the latter of which has merely 5Mbps of quality?".

If the answer is "no", which is my answer, just have simulcasting of
multiple sessions.

							Masataka Ohta

---

From: Peter Parnes <[email-masked]>
Date: Tue, 11 Aug 1998 09:19:39 +0200

> layered flows in a session by consequtive port numbers.

Hmm, the layered flows have to be on different mcast groups or the whole idea 
is sort of wasted.

> If the answer is "no", which is my answer, just have simulcasting of

I don't agree. Say we have a video stream divided into a number of layers. 
This would allow receivers to dynamically to receiver based congestion 
control. That is, when they notice that they have packet loss they just leave 
the least significant layer/s. This would increase the perceived quality for 
everybody!

On the other hand simulcast, would just increase the congestion. 

/P

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 Aug 98 16:32:57 JST

Peter;

> the least significant layer/s. This would increase the perceived quality for 

It seems to me that you make a fundamental mistake here.

You assume, seemingly, that, without signaling, a session can enjoy a fair
share of the bandwidth. That's impossible, because, without signaling,
routers do not know which groups belong to a session. A less impossible,
though not easy nor meaningful, thing is to allocate each multicast
group fair share. But your assumption here is let a session have
multiple multicast groups.

If you allow signaling and complex prioritization of packets, that's
resource reservation.

So, please, simply assume resource reservation.

Anyway...

> On the other hand simulcast, would just increase the congestion. 

Assuming that session-wise loss-based flow control had worked,
simulcast were just as good as layered encoding to adaptively reduce
the amount of traffic.

The difference is that picture with 6Mbps unlayered encoding has
better quality than that with 6Mbps layered encoding.

							Masataka Ohta

---

From: Larry Rowe <[email-masked]>
Date: Tue, 11 Aug 1998 17:26:46 -0700

Hi -

Assigning and managing layered multicast addresses is non-trivial, 
particularly when you have groups of people in clusters of high bandwidth 
links joined to another cluster and there is a low bandwidth link between the 
clusters.  A Berkeley student, Andrew Swan, worked on this problem.  A paper 
co-authored by Swan, McCanne, and myself describing one solution will be 
presented at ACM MM '98 in Bristol England next month -- in fact, the paper 
won the "Best Paper Award" for the conference.  You can see an earlier draft 
of the paper at http://www.bmrc.berkeley.edu/papers/1998/148/148.html.

Personally, I think layered streams are very important for supporting the wide 
variability in networking and client devices and avoiding the "least common 
denominator" a/v stream.
	Larry
-- 
Professor Lawrence A. Rowe               Internet:  [email-masked]
Computer Science Division - EECS         Phone: 510-642-5117
University of California, Berkeley       Fax: 510-642-5615
Berkeley, CA 94720-1776		 URL: http://www.bmrc.berkeley.edu/~larry

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Aug 98 13:34:10 JST

Larry;

> Assigning and managing layered multicast addresses is non-trivial, 

Assigning and managing layered multicast addresses is as trivial as
assigning and managing a single multicast address.

> clusters.

If you assume SAP, which makes assignment and management of multicast
addresses non-trivial, everything is non-trivial, of course.

If not, the problem is already trivial and solved.

> A Berkeley student, Andrew Swan, worked on this problem.

He is unfortunate to be assigned such a misdirected task.

The solution to the SAP problems is to ignore SAP.

There is no point to slightly improve some of the scalability
problems of SAP.

> A paper 
> presented at ACM MM '98 in Bristol England next month --

The basic problems of the paper are

	that there is no such layered encoding to allow meaningfully
	many layers.

	that it assumes SAP

> in fact, the paper 
> won the "Best Paper Award" for the conference.

Sigh...

OK. The paper may be a good paper as long as SAP framework is
assumed and layered encoding were meaningful.

However, the paper and the program committee needs a reality check.

							Masataka Ohta