Subject: [MMUSIC] RTSP: PLAY_NOTIFY

From: "HAAS Christian" <[email-masked]>
Date: Tue, 4 Nov 2008 10:37:25 +0100

Hello!

Regarding the PLAY_NOTIFY method I wonder why it needs to be called
PLAY_NOTIFY, and not simply NOTIFY;
The actual meaning of the message is derived from the "Notify-Reason" header
- an already neutral name - and its values. The context of the operation is
already referenced both through the media control (PLAY) and/or the
"Request-Status" header, which references the original request in question
(also, PLAY).

What I'm having in mind are later extensions, such as the dedicated RECORD
feature which as well might require the server to notify the client of an
event (like: disk full). Instead of creating another new method RECORD_NOTIFY
I'd simply like to reuse the existing NOTIFY with Notify-Reason and put in a
new reason value.

Skimming through the spec, a simple search/replace should be enough, and a
little of section 13.5 must be modified to be generic.
I originally brought this topic up on the dedicated mailing list on SF, but
would like to have it discussed here.

Also, a little more generically, having server initiated requests has some
side effects; One that came to my mind is the ABNF that separates request
headers from response headers;
User-Agent is bound to be a request header and Server is a response header -
but in the case of (PLAY_)NOTIFY, it's vice versa.

Regards,
ch
____________________________________________________
Christian Haas
Team DIVOS, Software Engineer
FREQUENTIS AG

Innovationsstraße 1, 1100 Vienna, Austria
Phone   +43-1-811 50 - 8353
Mobile   +43-664-60 850 - 8353
Fax       +43-1-811 50 - 77 8353
Web      www.frequentis.com
E-Mail    [email-masked]
 
Handelsgericht Wien (Vienna Commercial Court): FN 72115 b
DVR 0364797, ATU 14715600
____________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser E-Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden. 

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 7 Nov 2008 16:11:20 +0100

Hi Christian, 

[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: [email-masked] [mailto:[email-masked]] On
> Behalf Of HAAS Christian
> Sent: Tuesday, November 04, 2008 10:37 AM
> To: [email-masked]
> Subject: [MMUSIC] RTSP: PLAY_NOTIFY
> 
> Hello!
> 
> The actual meaning of the message is derived from the "Notify-Reason"
> header - an already neutral name - and its values. The context of the
> operation is already referenced both through the media control (PLAY)
> and/or the "Request-Status" header, which references the original
> request in question (also, PLAY).

It is a matter of taste, but the name was chosen to avoid confusion about
in which context this method can be used. 

> 
> What I'm having in mind are later extensions, such as the dedicated
> RECORD feature which as well might require the server to notify the
> client of an event (like: disk full). Instead of creating another new
> method RECORD_NOTIFY I'd simply like to reuse the existing NOTIFY with
> Notify-Reason and put in a new reason value.

Well, there is of course always space for extensions but the current
documented use case is in draft-stiemerling-rtsp-announce. A future use
case does not help, as there are many of them ;)

Anyhow, the semantics of PLAY_NOTIFY are somewhat depend on the PLAY
status and in other yet defined states we do not need an asynchronous
notification. 

  Martin