Subject: SDP attributes for time

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 28 Jan 1998 10:30:05 -0800

The draft spec appears to imply that it is not legal to have attributes for
the time fields, t and r.  Is this a correct interpretation?  If so, can
someone elaborate the rationale and/or point me to a discussion thread?

If not, there is an attribute that may be of interest to the group.  It is
basically a time exclusion qualifier that simplifies the t/r pair expansion
considerably when representing things such as "weekdays during working
hours only", but otherwise has a regular broadcast schedule.

An example of "continuous broadcasts every hour weekdays during working
hours" would then be:

t=0 0
r=1h 1h 0
a=time-only:times 0800-1700 (converted to GMT)
a=time-only:days Mon Tue Wed Thu Fri

Additionally, there could be an analogous "a=time-exclude" qualifier.

The t/r only version of the above gets kinda messy and long.

Comments on permitting such attributes?

Thanks,
	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: Wed, 28 Jan 1998 13:38:38 -0500

>someone elaborate the rationale and/or point me to a discussion

It hasn't been considered, but you couldn't use attributes in this way
without significant changes to the SDP semantics.

>r=1h 1h 0

This doesn't make sense.  "Repeat every hour for one hour".

>The t/r only version of the above gets kinda messy and long.

Actually your version is four lines.  The t/r version is only 2 lines.

t=start-time 0
r=7d 9h mon-offset tues-offset wed-offset thurs-offset fri-offset

where the offsets are offsets from the start-time to 8am on the first
monday, etc

Cheers,
	Mark

---

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 28 Jan 1998 11:31:39 -0800

>without significant changes to the SDP semantics.

Any chance at considering this?

>This doesn't make sense.  "Repeat every hour for one hour".

I think this means "broadcast a one hour long session every hour on the
hour indefinitely".  It may be clearer to have a more realistic start time,
but that doesn't seem to change the net result to me.  Am I confused about
r=?  I have assumed when r= is present that an end time of zero meant that
there was no end to the set of broadcasts, not that it implied the
broadcast was continuous in nature.

>where the offsets are offsets from the start-time to 8am on the first

Yes, but there is a 9x expansion for each of the 5 offsets in the t/r only
solution above, so the r= line is pretty long, especially if one is forced
into NTP times (and not "1h" syntax).  I chose a fairly simple example to
demonstrate the idea.  More complex examples that force multiple t/r pairs,
even lengthier r= strings with NTP times are worrisome.  In addition to the
general complexity of the expressions, it pushes the SDP record size
towards the 1024 byte boundary,  especially when coupled with our other
(robust set of) attributes.  Hence the desire to make the expression more
compact.  It is not at all desirable to create multiple SDP records for the
same broadcast content.

This is all moot of course, without the enabling semantics.

If a semantic change is not in the cards, how do you feel about a
discussion of the 1024 byte limitation?

Thanks,
	Mike

---

From: Mark Handley <[email-masked]>
Date: Wed, 28 Jan 1998 14:54:32 -0500

>broadcast was continuous in nature.

The intention is that SDP time fields add to specify when the session
is active.  r=1h 1h 0, although not actually incorrect, therefore
indicates a session that is always active.

If this were not the intended meaning, then you need to check your
repeat fields to ensure that their time intervals will never overlap,
or at that time the session would be active twice.

Mark

---

From: Mark Handley <[email-masked]>
Date: Wed, 28 Jan 1998 15:01:27 -0500

Please note that SDP has been though working group and IESG last call.
The IESG ballot on it is tomorrow.  The only changes being considered
are any _required_ by the IESG for SDP to move to Proposed Standard.

SDP has been an Internet Draft for more than 3 years now.  It could
continually evolve and never be standardised if we let it, but this
would be a very bad idea.  After it becomes a Proposed Standard, there
is the opportunity to make any essential changes before it moves to
Draft Standard.

Mark

---

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 28 Jan 1998 13:43:43 -0800

If this revelation is obvious to the list, then my appologies for this
posting.  But several of us here read the r= section of the spec pretty
differently than what Mark intended, so thought there might be others...

>indicates a session that is always active.

We thought "repeat" meant a repeat of the session.  So when r= was present,
the t= specified a total period of the repetition set, and the r= the start
and duration times for each session.  If I understand you correctly, then
one must include a t= (or t/r pair as needed) for every repetition of a
session, yes?

By example, your intent was for r= to handle something unusual like a space
shuttle broadcast?  Where t= specifies the mission duration, and r= defines
when it is actually broadcasting.  This, in contrast to describing a
(repeated) broadcast of the evening news every night at 6pm with a single
t/r pair.

You may wish to consider clarifying this section to note that r= is an
inclusion qualifier on a single session period noted by the preceding t=,
and not a repetition specification of the session itself.  Use of the term
"repeat" I think led us astray.

Your intended meaning of r= aggravates my original size and session
repetition problem, though, so I need the session repetition field more
than ever.

However, would it now be reasonable to make this and our other time
modification attributes be session attributes, and thus avoid the time
attribute semantic dilemma?

	Mike

---

From: Mark Handley <[email-masked]>
Date: Wed, 28 Jan 1998 16:54:44 -0500

>one must include a t= (or t/r pair as needed) for every repetition of a

Any combination of t and r fields indicate additional time when the
session is active again.  The session will be active for the union of
the time intervals specified.  Neither t nor r make any comment on the
content of the session.  

If your session is the same thing repeated again and again
continuously with no break, there is no way to indicate this in SDP
without using attributes.

>(repeated) broadcast of the evening news every night at 6pm with a single

Actually the shuttle is best handled with t fields alone because the
timing is irregular.  The 6 o'clock news is handled fine with a single
t/r pair very well because the timing is regular.  

What this doen't handle well is something like a tape on continuous
repeat where you also want to indicate when the tape rewinds and
starts again.  SDP has no way to indicate repeats of the content, only
that the session became active again.  Is this the sort of thing you
are trying to indicate?

Cheers,
	Mark

---

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 28 Jan 1998 14:50:34 -0800

At 04:54 PM 1/28/98 -0500, Mark Handley wrote:
>
>SDP has no way to indicate repeats of the content, only

Yes.  I think we are back to a fundamental difference in describing the
broadcast of continuous streams versus discrete objects.  If I understand
correctly, your intent for SDP is for it to indicate simply that the "a
stream is flowing".  This is fine for a continuous stream, but doesn't work
very well for broadcast of streams that have a definite beginning and end
to the content that must be communicated to the client.

It looked to us like r= would do this, but we apparently read more into the
spec than you intended.  I infer from your replies (which I greatly
appreciate BTW), that you are opposed to this use of t/r to convey this
content information, and it should be restricted to just describing when
the bits are flowing?

On this assumption, then our SDP records will really need to look more like:

a=session-content-time:<our content time needs, including repeats, etc...>
t=0 0

We could use IP/port to delineate these objects, but there would be an
unacceptable proliferation within these name spaces.  We could also create
a separate SDP record for every repetition of an object, but that too
creates an overload of records to process for what is basically the same
information.

Any other suggestions on how to convey this discrete content time info?

Thanks,
	Mike