Subject: [MMUSIC] RFC2326bis: A proposal about document size

From: Martin Stiemerling <[email-masked]>
Date: Fri, 5 Oct 2007 15:36:51 +0200

Hi all,

draft-ietf-mmusic-rfc2326bis has currently an overall page count of  
214 pages
(http://www.ietf.org/internet-drafts/draft-ietf-mmusic- 
rfc2326bis-15.txt)
and I doubt that many people have read the draft in the past as a  
whole... ;-)

After considering which part of the draft could shorten or moved to a  
different draft, I have have ended up with this as my personal  
conclusion:

Appendix B "Media Transport Alternatives" and Appendix C "Use of SDP  
for RTSP..." could be moved in separate drafts, as both are not  
necessarily part of RTSP itself, even though there somewhat required  
for operating RTSP.  However, this "required for operating RTSP"  
holds true in some environments, but not in all. For instance, in DVB  
network RTP is probably not used, but MPEG-2 TS. Same for SDP, as  
some might use it, some might not.

Appendix B could be moved to a draft "Using RTSP with RTP as media  
transport" and Appendix C "SDP usage in RTSP" (titles are just  
suggestions!)

This would reduce the size of the draft, but, even more important,  
would clearly separate between the RTSP protocol and further  
protocols required by some architecture to build media delivery  
platforms.

Any thoughts, suggestions, objections?

Thanks,

   Martin (draft-ietf-mmusic-rfc2326bis editor)

[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

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 5 Oct 2007 17:00:51 +0300

Le Friday 05 October 2007 16:36:51 ext Martin Stiemerling, vous avez écrit :
> holds true in some environments, but not in all.

> For instance, in DVB 
> network RTP is probably not used, but MPEG-2 TS.

Do you mean TS over RTP, or TS over plain UDP?

I know uses of both, though I think the second one should really be heavily 
discouraged. Apparently, it screws up completely whenever there is packet 
re-ordering.

> Same for SDP, as some might use it, some might not.

I agree that the spec is way too long, but removing essential parts may just 
make matters worse. At the end of the day, it makes the entire thing even 
longer, that's why... I mean, what's the use of an RTSP stack without RTP 
(especially when raw TS over UDP is so broken).

I would have thought of moving all the proxying stuff to a separate document, 
à la MSRP, perhaps.

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Oct 2007 10:19:45 +0200

Hi,

I think we should be careful of splitting of to much normative functions
into other documents. I think one of the more important things is to
make it more readable. I think the main problem is the initial sections.
I also think there is some informative text that could be moved into
some separate purely informative document. But I wonder if that really
can be moved in way that will make sense. I think we will need to look
into this more.

> Do you mean TS over RTP, or TS over plain UDP?

I don't think this matter as RTSP is intended to possible to use with
any media transport. However, that media transport must specify the
equivalent to Appendix B. But TS over RTP falls under the RTP usage, so
I think Martin meant MPEG-2 TS over UDP.

> (especially when raw TS over UDP is so broken).

Well, this is actually a pluggable part. And I think this will make it
clearer that there is the signalling and then one or more media
transports being negotiated. But if this is a real benefit or not I
wouldn't say. The end result will be that there will be more pages to
read in total.

> I would have thought of moving all the proxying stuff to a separate document, 

I far from convinced that this is the right move. However, we probably
should look into this. The important is that we then must succeed to
only move functionality that really are valid for the proxy only. In
cases the client or server must be aware of the proxy, these functions
must be specified in the base spec. I don't know how easy this is.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------