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 christian.haas at frequentis.com
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 mmusic at ietf.org https://www.ietf.org/mailman/listinfo/mmusic