Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt

[Rémi Denis-Courmont <rem at videolan.org>]

Le lundi 3 novembre 2008 20:30:01 Internet-Drafts at ietf.org, vous avez écrit :
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-19.txt

| 2.2.  RTSP's Relationship to HTTP
| (...)
|    *  Both an RTSP server and client can issue requests.

I am not questioning the need for this. But it might be worth to mention 
somewhere that RTSP agents MUST be ready to handle an incoming requests even 
when they are "waiting" for a response to one of their own requests. Without 
this, we might get into a race condition failure scenario.

Also, RTSP agents MUST be ready to dequeue incoming (chunks of) requests 
whenever they are in the middle of sending a request in the other direction. 
Otherwise, they could get into a complete deadlock if a full request is 
bigger than the TCP receive buffer.

| 13.4.1.  General Usage
| (...) Range: npt=10-15, npt=20-25, npt=30-

I never really understood the need for multiple ranges. It's impossible to 
support this with a user-grade interface. And for advanced uses, I don't see 
the advantage over using multiple PLAY requests (I do see the big 
inconvenience that it's a burden for server vendors to implement, and in fact 
our RTSP server never supported this and will continue to ignore such 
requests).

| 16.19.  CSeq

I wonder why we have it at all. I assume I must be missing something. It made 
sense for rtspu, but now? It is quite trivial to implement for clients and 
servers, but not for proxies.

| D.1.6  Range of Presentation
|  (...) In case of
|  different length the range attribute MUST be given at media level
|  for all media, and SHOULD NOT be given at session level.

This will for sure cause interoperability problems if it's ever used. The 
basic video player for A/V streams won't know what to cope with that.

| D.1.8.  Connection Information
| (...) for type "IP6", this value SHALL be "0:0:0:0:0:0:0:0", i.e. the
| unspecified address according to RFC 4291 

The canonical notation for the unspecified IPv6 address is "::". Then again, 
it might be better to not put an explicit quoted value. The value matters, 
not its notation.

| Appendix J.  Acknowledgements
| (...) Mela Martti

Hist name is Martti Mela.

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic