Subject: feedback on some attributes requested

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 07 Jan 1998 16:00:08 -0800

Folks-

I'm new to this list, so first my appologies if these or similar topics
have been discussed/dismissed in the past and/or these extensions seem
otherwise inane or out of context.

What I am looking for is some feedback on whether these make any sense,
follow accepted practice, etc. before we cast them in stone here in an
implementation.  

These will be used in a one-way network with no backchannel communication
at all.  The multicast streams they point to can contain streaming data of
various formats, including a related collection of discrete objects, such
as files.

First, we felt we needed some extensions to the UDP stream types of the m=
tag.  This, as opposed to using the a=fmtp, since we only needed a single
token identifier.  As best as I could tell, this seemed OK, so for:

m=data <port> UDP <fmt list>

where <fmt list> is one of:

	BFDP (a proprietary file transfer protocol)
	STREAM (generally unknown content usable by a local program more
			fully specified with a=run below)
	WEBCAST (a special case of BFDP)

There are others, but you get the idea.

Now for the a= fields...

a=mandatory
	Signifies that this is a "mandatory", and require special attention and
handling from the local client.

a=key:<number>
	Number is a 32-bit unsigned decimal number which identifies the object
within a stream nominally pointed to by the multicast group and dest port.

a=run:<prog>
	prog = well known program on the client that will be run.  Note that this
program is run as follows:  When the media type is a STREAM and the record
is mandatory, then the program will be run immediately on receipt of a new
SDP record version; and will be run any time the system is tuned to a
tranponder which contains this service.  For BFDP media types, the program
will be run on receipt of a final valid file.  For WEBCAST, the run tag is
not permitted and is ignored.   Additionally, the PATH is searched for
"prog" as follows:

	<installpath>\Download\
	<installpath>\Bin\
	$PATH according to the OS search rules, but only for relative pathnames
	any absolute pathname (if supplied)

Each level of search is controlled by a security level parameter settable
locally by the user.

a=cat:<category>[.<subcategory1>.<subcategory2>...]
	This is the same as the field defined in the draft spec, but we permit
multiple fields per record (ie a=cat:Sports and a=cat:News, which are
heirarchically related).  This may be the same as proposed, but it wasn't
clear.

a=rescind
	Used to rescind (delete) the session with the same session ID.  This is
needed since the SDP records are cached and obtained from multiple sources
(with priority).  So, the omission of an SDP record in one stream is not
adequate to eliminate it.

a=fsz:<nbytes>
	nbytes is the number of bytes in the (file) object that this record
describes.

a=notify
	Causes the information in this particular SDP record to be immediately
presented to the user upon receipt in some special manner.

a=channel:<number>
	where number is a client-dependent channel number associated with this
stream.

a=archived
	Indicates that this item is in a client-dependent archive format.
Unarchiving after receipt will occur automatically.

a=display:type=<t>,priority=<p>

	where t is display type indicator used by the client; and
	p is a display priority
	these are used by the client to control display positioning and visibility

Comments very welcome, and thanks in advance.

Regards,
	Mike

---------------------------------------------------------------------------
Michael A. Dolan  TerraByte Technology  (619)445-9070    FAX: (619)445-8864
PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd, Alpine, CA 91901
URL:http://www.tbt.com

---

From: Mark Handley <[email-masked]>
Date: Thu, 08 Jan 1998 11:34:36 -0500

>There are others, but you get the idea.

BFDP and WEBCAST would be OK with me.  STREAM I would like to avoid.
In general you'd like the receiver of a session description to be able
to make a decision as to whether it can support a medium and which
tool to use to support it by looking at as few fields as possible.
STREAM doesn't tell you anything, and so forces you into looking at
attributes to discover anything at all about the stream being
described.

>Now for the a= fields...

You need to specify whether these are session level, media level or
both.

>handling from the local client.

I'm not sure what you mean by this.

>within a stream nominally pointed to by the multicast group and dest port.

Again, this doesn't make sense without more context.

>Each level of search is controlled by a security level parameter settable

This is a bad idea.  You want to describe media streams and not pieces
of software, and you especially want to avoid client OS dependencies.

In addition, if the session description is in a session announcement,
the security requirements of SDP dictate that to DO NOT run any
program without explicit permission of the user.  

>heirarchically related).  This may be the same as proposed, but it wasn't

The spec does allow multiple cat attributes.

>adequate to eliminate it.

This is not in the spirit of SDP.  The transport mechanism (eg SIP,
SAP, RTSP) is responsible for deletion not the description itself.

>	nbytes is the number of bytes in the (file) object that this record

In general, SDP describes streams not files, but a stream could be
fixed length, so this would be OK so long as you made it clear.

>presented to the user upon receipt in some special manner.

This is not in the spirit of SDP.  The transport mechanism (eg SIP,
RTSP) is responsible for this if the functionality is provided at all.
Imagine I sent many SAP announcements containing this to the global
group - everyone in the world would be getting all these windows
popping up!

>	where number is a client-dependent channel number associated with this

Probably OK, but your description is unclear.

>Unarchiving after receipt will occur automatically.

I don't understand this one.

>	these are used by the client to control display positioning and visibil

I don't think I like this, but it's hard to tell from your description.

Hope these help, although they're probably not what you want to hear.

Cheers,
	Mark

---

From: "Michael A. Dolan" <[email-masked]>
Date: Thu, 08 Jan 1998 09:46:42 -0800

Mark-

Thanks very much for your comments.  Sorry some of the attributes were
vague.  First here, I will try and expand on the ones that were not clear.
I'll reply to your other comments under separate cover...

>I'm not sure what you mean by this.

The idea is that if this tag is present, the client will take some
extraordinary measure to ensure that the stream described by this record is
received and processed.  This may, for example, be a stream/object that
contains a more robust description of the announced streams.  It is
envisioned that the client would cause this to be processed without human
intervention.

>Again, this doesn't make sense without more context.

In a stream that contains multiple objects, this key identifies which
object this record describes.  For example, for a file object, the header
of the file transfer protocol would contain this identifier.  It is
generically a sub-stream object identifier.

>Probably OK, but your description is unclear.

This is generic and of an informative nature similar to a=cat.  This is
literally a channel (ie 100) that this record describes, which may have
meaning only to the program that processes the stream, or to the user
interpreting this record.  In a simple example, if a stream were a
broadcast of channel 4 in Los Angeles, then this would be set to 4.

>I don't understand this one.

This is a somewhat incomplete thought and hence will require more
definition when we get around to actually doing it.  But the general idea
is that the object within the stream that this record describes is in fact
a collection of objects, and not just a single object.  For example, it
could be a tar file.  This would be used in conjunction with the a=key.

>I don't think I like this, but it's hard to tell from your description.

As you have probably intuited from the above explanations, our client that
is processing these records is fairly sophisticated.  It is automatically
generating a rich display to the user based on the SDP records, as well as
other information contained in special (mandatory) streams.  As such, we
wish to have commands to control the display of the information to the
user, giving some SDP records display preference in some manner over
others.  Also, we wish to provide a means of grouping the information,
independent of category.  The "type" is for the grouping.  The "priority"
is the priority of display WRT other SDP records.  The exact interpretation
of these is somewhat client-dependent.

>Hope these help, although they're probably not what you want to hear.

I LIKE the feedback.  Hope these explanations help.

Thanks,
	Mike

---

From: Mark Handley <[email-masked]>
Date: Thu, 08 Jan 1998 13:12:44 -0500

>generically a sub-stream object identifier.

The media-level description describes a stream.  I'm not clear how it
can describe anything smaller than a stream, hence this field still
doesn't make sense to me.

>broadcast of channel 4 in Los Angeles, then this would be set to 4.

You would then have to state that you couldn't use this in a global
session announcement unless the value had global meaning.

For example, I can't put this in a global (or even National in the US)
session announcement, and I can't use it in SIP or RTSP unless I share
prior common knowledge with the invitee/server/client that defines the
meaning of the value.

I suspect this applies to a lot of your attributes, so I can't see
how they're used.

>could be a tar file.  This would be used in conjunction with the a=key.

By itself, I don't think this tells me anything, and I still don't
really understand how key is used.

>of these is somewhat client-dependent.

Ok, so now I don't understand why everyone won't set the maximum
priority on their sessions?

If you're using this in the context of SAP, you probably can't perform
any useful form of sender controlled prioritisation.  All you can do
is provide sufficient information for a smart receiver to filter the
incoming announcements.

If you're using this in some other context, then I'd need to know what
the context is to be able to judge the attributes, and the attribute
specs would need to state what the intended usage context is.

Cheers,
	Mark

---

From: "Michael A. Dolan" <[email-masked]>
Date: Thu, 08 Jan 1998 11:41:15 -0800

>doesn't make sense to me.

First, no problem if any of these attributes are too goofy to incorporate
into your draft spec.  My goals in order were to get some feedback (this is
going great), seek input from anyone with similar needs, possibly
standardize anything as it makes sense globally, and educate the group on
our needs in case someone else sees any benefit/use in their work.  So, as
we discuss these, and you have a better feel for our application, feel free
to simply dismiss attributes from further global discussion.

Some more background which hopefully will help...

Among other things, we have an need to broadcast files.  We developed a
transfer protocol to send these as datagrams using multicast group
addressing.  For performance, bandwidth, and namespace considerations,
there must be multiple files per "stream".  Thus we need some form of
sub-stream addressing.  Using time alone is not practical as the time
windows are sub-second.

For example, if one has a 100Mbps ethernet, a file is only 1000 bytes, and
the broadcaster is using high bandwidth (even 1/10 capacity), computer
networks simply cannot be this accurate on when to join/leave the multicast
group.  In addition, the broadcaster can't even specify the time window
accurately even if the network could respond.  Since we wished to use a
semi-standard way to describe these objects, we chose SDP.  We could have
invented something else, but we also have other things that are much more
like what SDP was designed for, so we stuck with SDP for everything.

In the file case above, the time field in the SDP record specifies a
reasonably wide range from which to join and leave the group (may only be a
matter of a minute), and the a=key lets the application pick out the right
object (in a stream-dependent way) during that time window.

There are many thousands of files being broadcast, and thus it is not
practical to spread them out in time over the bandwidth on a single stream
for each.

Additionally, we found that it was useful to have the object id be a one to
many  mapping.  For example, if there were a logical collection of files
distributed over a well known time window, they could ALL be picked from
the stream with a single a=key, and hence single SDP record.  Then, a much
wider time window can be used in some cases.

This application is probably not what you had in mind for SDP, huh?

>I suspect this applies to a lot of your attributes, so I can't see

A geographically local terrestrial broadcast channel is not what we use
this for, but was just an example that I thought was somewhat generic.  Do
the address spaces of the attribute values have to be global?  If so, then
this attribute will obviously not work in a standard (if only there were a
global channel name space !).  But, if the meaning and space can be context
dependent to the rest of the SDP record, then it seems that this is useful,
and somewhat standard information for many broadcasts.  A "channel" means
different things to different folks, but nevertheless is useful in context.

>really understand how key is used.

Hopefully the discussion above helps this.  And, as I mentioned, the
details are still being "cooked".  I just wanted to run the basic idea by
you, without any suggestion that it be standardized in any way at this time
- just offer the discussion on the outside chance that someone else had
done something similar.  But it implies sending files in the first place, etc.

>priority on their sessions?

Yep.  Human nature would prevail.  However, groups of SDP records are often
created by the same entity.  So, within any given entity's set, this is
still valuable.  In the case where the SDP creation is a closed system
(only one author), then it is perfect.  In the case where the SDP creation
is open and from uniformly distributed sources, then this is probably not
so useful, as you point out.

Our application is initially a semi-closed system.  The announcements are
being carefully coordinated and controlled by a single entity, including
the display attributes.

	Mike

---

From: Mark Handley <[email-masked]>
Date: Thu, 08 Jan 1998 15:02:17 -0500

>into your draft spec.

Actually I should make it clear to everyone that _no_ additional
attributes will make it into the draft SDP spec before it becomes an
RFC.  No new attributes have been added to this spec for many months
or we'd never get to the point where it stops changing.

At the time it becomes an RFC, there should be a mechanism whereby new
media, protocols, formats and attributes can be registered through
IANA.  That process is not completely decided yet.

In principle, anyone can use any attributes they choose, and everyone
else will just ignore them.  However I believe it is a good idea to
have a registry and some form of review of registered attributes to
ensure chaos doesn't develop and attributes with common purpose
evolve.

Mark

---

From: "Michael A. Dolan" <[email-masked]>
Date: Fri, 09 Jan 1998 11:52:22 -0800

>BFDP and WEBCAST would be OK with me.  STREAM I would like to avoid.

STREAM was left over from an early iteration of the design, and I agree.

>You need to specify whether these are session level, media level or

Good point.  In our application, there are currently not multiple media
descriptors being used, so we got sloppy about where the attributes
belonged, since session == media.

>of software, and you especially want to avoid client OS dependencies.

We felt that the locally controlled security level addressed this
adequately, where one setting was disabling the executions entirely.  The
problem is that if you have automated processing of the SDP records and the
streams they point to, you necessarily must be able to specify that some
local action take place under certain conditions that theh user is simply
unable to grok.

In hindsight, most of our requirements would be satisfied by using MIME
type specifications of the stream, then relying on local type
mappings/associations as to exactly what should get executed.
Unfortunately, not all cases are covered by this, so we see no way around
the requirement to cause some local program execution at some level -
directly or indirectly.  This certainly can be limited to it being a media
attribute if that helps.

>program without explicit permission of the user.  

In our semi-closed system all SDP records are currently received via "an
authenticated transport protocol from a trusted source".  And, since it is
a one-way network, there is no interactive or transmit session possible.
hopefully this helps, too.

>SAP, RTSP) is responsible for deletion not the description itself.

We believe SAP is inadequate for this function, and we did not investigate
these other transports - thanks - we'll look into it.

>fixed length, so this would be OK so long as you made it clear.

As in the previous email with the file object description, this is
generally the length of the object within the stream, not the length of the
stream (although it could be).  In our application, it does not have to be
an exact value.  It is used only for planning purposes in the event the
stream/file is to be saved to local disk.  For example, if
a=fsz:1000000000, and there is not this much disk space left, then the user
is notified before it starts using it all up.

Thanks again for all your comments.  We will try to revise our thinking as
we move forward to be consistent with the spirit of the spec.

	Mike

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 09 Jan 1998 23:23:07

>or we'd never get to the point where it stops changing.

Agreed.  SDP appears stable now, so it's important that it get standardized
soon.

It's also worth pointing out here that - for describing things that just
aren't a good fit for SDP - one might consider an alternative format that
gives you the flexibilty you desire.

This is what I've been trying to do with MAFP (the "Multicast Attribute
Framing Protocol" - see <http://www.lvn.com/multikit/mafp-list-info.html>).
 This takes the (many) good ideas in SDP, but generalizes it to allow
arbitrary attributes, arbitrary bundling of subsessions, directories as
'first class objects', etc., etc.

Things that clearly fall into the SDP model - e.g., audio/video sessions -
should continue to be described using SDP.  But perhaps some of the things
Michael Dolan is trying to do might better be described using an
alternative protocol??

	Ross.

---

From: "Michael A. Dolan" <[email-masked]>
Date: Sat, 10 Jan 1998 07:48:02 -0800

Ross-

Thanks for jumping in.

>gives you the flexibilty you desire.

This is a good point, and we considered it.  However, we didn't want to
support 2 different announcement generation systems (and hence
interpretation systems) for similar, if different streams.  Some of what we
are sending is a pretty good match for SDP.  The problem is that there is
all this other stuff, too...

>'first class objects', etc., etc.

Interesting stuff.  Thanks for the pointer.  I'll review it in detail...

	Mike