Subject: [MMUSIC] RTSP: Contradicting text in RFC2326bis and RFC 2616

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 26 Feb 2009 14:06:03 +0100

Hi all,

Just to clarify the intended use of the Date header field.

draft-ietf-mmusic-rfc2326bis-19.txt says this in Section 16.20. "Date":

   See [H14.18].  An RTSP message containing a body MUST include a Date
   header if the sending host has a clock.  Servers SHOULD include a
   Date header in all other RTSP messages.

When adding the text out of [H14.18] to RFC2326bis we end up with this,
as the text "Servers SHOULD include a Date header in all other RTSP
messages." contradicts the text in RFC 2616:

   Origin servers MUST include a Date header field in all responses,
   except in these cases:

   1.  If the response status code is 100 (Continue) or 101 (Switching
       Protocols), the response MAY include a Date header field, at the
       server's option.

   2.  If the response status code conveys a server error, e.g. 500
       (Internal Server Error) or 503 (Service Unavailable), and it is
       inconvenient or impossible to generate a valid Date.

   3.  If the server does not have a clock that can provide a reasonable
       approximation of the current time, its responses MUST NOT include
       a Date header field.  In this case, the rules in section 14.18.1
       MUST be followed.

Any guidance is welcome :)

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 26 Feb 2009 15:48:39 +0200

> Just to clarify the intended use of the Date header field.

If the server has no accurate clock, it simply cannot fill the date field 
(with meaningful informations at least). I guess dates are mostly useful for 
caching, which is possibly not very relevant for RTSP.

At least, you surely cannot do media-level synchronization with that date, 
since the inaccuracy will likely be too high for such purpose.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D

---

From: "Jaehwan Kim" <[email-masked]>
Date: Fri, 27 Feb 2009 18:53:54 +0900

Hi Martin,
Yes. It looks like contradiction at the text of
draft-ietf-mmusic-rfc2326bis-19.txt. You might simply remove 2326bis'
and remake new text...

1.  If the response status code is 100 (Continue) or 101 (Switching
       Protocols), the response MAY include a Date header field, at the
       server's option.
[jh] 100 came from HTTP but still meaningful even in RTSP.
 
   2.  If the response status code conveys a server error, e.g. 500
       (Internal Server Error) or 503 (Service Unavailable), and it is
       inconvenient or impossible to generate a valid Date.
[jh] yes. The purpose of Date header is 1) cache, 2) logging, 3) a
reference of the management of system for different locations or
countries. But not the all case we can make Date. One use case would be
the disconnection between server and realtime encoder. Still we can make
a date which could be very useful for the analysis of the problem.

   3.  If the server does not have a clock that can provide a reasonable
       approximation of the current time, its responses MUST NOT include
       a Date header field.  In this case, the rules in section 14.18.1
       MUST be followed.
[jh] RTSP allows client sends Request. Then, this is not limited just to
Server, but also to client. But is there anyone who saw so-called 'no
clock server or client'? In case of HTTP, it might be. But in RTSP
server? We use timestamp in RTP or whatever we call 'streaming media',
don't we? If it is not the case for RTSP, we are happy with simple text
with above only two cases.

Regards,
Jaehwan
Vidiator