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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 03 Mar 2009 16:37:42 +0100

Martin Stiemerling skrev:
> 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 :)
> 

Hi,

RTSP still maintains the methods for caching or asking if content is up
to date that are based on date. That is why Date is mandated for
messages with bodies. And that goes both ways between client and server.

Secondly date is good for debugging that is why it should be included in
all other messages. But of course if you don't have a clock then it is
no point in including it.

I would also like to point out that the RTSP text that overrides the
HTTP one is intended to be saying the same thing. I would keep the RTSP
specific text as it removes a few HTTP specifics that doesn't mean
anything for RTSP.

Changes are basically:

1. Mandate Date for both server and clients if they contain body content
that may use the up-to-date methods.

   a. With the exception if the clock is missing, i.e. case 3 in HTTP

2. Recommend the inclusion instead of saying MAY for other messages. As
RTSP has more messages without content this more generalized explanation
is more applicable then the exceptions in 1 and 2 from HTTP.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 4 Mar 2009 11:30:27 +0100

Fixed in the draft. 
Text is in the CVS:
http://rtspspec.cvs.sourceforge.net/viewvc/rtspspec/draft-ietf-mmusic-rfc2326bis/draft-ietf-mmusic-rfc2326bis.xml?revision=1.166&view=markup

Thanks,

  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 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, March 03, 2009 4:38 PM
> To: Martin Stiemerling
> Cc: [email-masked]
> Subject: Re: [MMUSIC] RTSP: Contradicting text in RFC2326bis and RFC
> 2616
>