Subject: Re: SDPv2 and URL's

From: [email-masked] (Ross Finlayson)
Date: Tue, 9 May 1995 12:00:33 -0700

> >I propose to allow multiple u= fields, and associate an optional
> >description with each one, i.e.
> >
> >u=http://sc94.ameslab.gov General information
> >u=http://sc94.ameslab.gov/AP/glance.html Schedule
.....
> The reason why I suggested a single URL is simply that we should
> attempt to move away from full descriptions of sessions in the "i"
> field.  The Web is now sufficiently prolific that the norm should be
> for most of a session description to be on the WWW server.  If only a
> single URL is allowed, this tends to encourage this.  If we allow
> multiple URLs then people will probably continue the current method of
> having long descriptions.

In general I tend to have a strong negative reaction to attempts at
social engineering - even otherwise well-intentioned ones like this.
Let's stick to network engineering.

If people want to include more than one URL in their session announcements,
then they're going to do so, whether we want them to or not.  The only
issue, then, is whether we want to make available a mechanism that will let
them do so in a way that SPD clients can easily handle.  Given the enormous
popularity of the WWW, this seems like a good thing to do.  Bill Fenner's
suggestion sounds reasonable; another approach would be to endorse a
specific (and unambiguous) way of representing URLs in the i= field.
(This is apparently what the newest sd.tcl script - which I guess I haven't
seen - is trying to do.)

> As the number of announced sessions increases, the proportion of
> sessions people want to see much information about decreases, and the
> more you want SDP sessions to convey only essential information.  If
> you're going to the effort to put a multicast together, then surely
> you should be prepared to put together a few lines of description on
> the Web which can easily then link to other relevant information?

Again, this sounds like an attempt at social engineering.  Limiting the size
of announcements may be good network engineering (e.g., to control
bandwidth), but if we do this, we shouldn't then worry too much about how
the announcements are being used.  (Suggested usage policies, style guides,
etc. might come later, especially once we get more experience.)

	Ross.