Re: [MMUSIC] [AVTCORE] Question

[Stephan Wenger <[e-mail]>]

Hi,

Dropping AVTcore, and focussing on RTSP only.

Work has been ongoing for many years towards an RFC 2326bis, and that
document has recently been approved and will obsolete RFC 2326 once the
downrefs are resolved and the RFC editor is done with it.  See attached.
I vaguely recall that I saw BNF for at least the ssrc parameter.  Suggest
that you study that document, it may address a lot of the RTSP issues you
seem to propose to solve by errata (inappropriately, IMO, but that¹s
another issue where you have received guidance on before, by folks more
competent than myself).

Stephan

On 1/6/15, 11:22, "Dale R. Worley" <[e-mail]> wrote:

>I'll note that I've received this message directly
>
>Julius Friedman <[e-mail]> writes:
>> As for my other 'issues' / errata for RFC2435 has anything been
>>determined
>> on them?
>
>Not yet, clearly.  What are you going to do to get them discussed?
>
>> I will include their questions here again and I would appreciate a
>>single
>> complete and through reply.
>
>That is the least effective way to get your issues handled.
>
>First, you are *demanding* something, and that always makes people less
>interested in helping you.
>
>Second, you want a "single complete and through reply", which means that
>if someone doesn't feel like doing all the work to do that, they won't
>bother to do any of the work.  That is, it minimizes the chance that
>you'll get any response at all.
>
>A better approach would be to select one problem, the one you think
>other people are most likely to recognize as a problem, and ask about
>it.  Also, add whatever discussion you can provide, to indicate that
>you've done as much work on the problem as you can before asking others.
>
>It seems to me this one would be a good one to start with:
>
>> What about my questions regarding the 'source' and 'ssrc' parameters?
>>Those
>> aren't proposals, those are genuine questions.
>
>Note that while RFC 2326 talks about a 'source' parameter, it doesn't
>provide any BNF for it.  Suggest that it probably has the same BNF as
>the 'destination' parameter.  Show that BNF.  Show all the examples of
>source parameters that you know of (mention what devices generate them),
>compare them to your suggested BNF.  Add your discussion of security
>questions.
>
>Once you've solicited as much feedback as you can get, organize all that
>information into a well-written errata for the RFC.
>
>Then go on to the next issue.
>
>> As for my other 'issues' / errata for RFC2435 has anything been
>>determined
>> on them?
>
>http://www.rfc-editor.org/errata_search.php?rfc=2435&rec_status=15&present
>ation=table
>
>All of your errata on RFC 2435 have status "reported", so it appears the
>answer is "no".
>
>Dale
>
>_______________________________________________
>mmusic mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mmusic

--- Begin Message ---

The IESG has approved the following document:
- 'Real Time Streaming Protocol 2.0 (RTSP)'
  (draft-ietf-mmusic-rfc2326bis-40.txt) as Proposed Standard

This document is the product of the Multiparty Multimedia Session Control
Working Group.

The IESG contact persons are Gonzalo Camarillo and Richard Barnes.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/




Technical Summary

The document defines RTSP version 2.0 which obsoletes RTSP version 1.0
defined in RFC 2326.

The Real Time Streaming Protocol, or RTSP, is an application-level protocol
for setup and control of the delivery of data with real-time properties.
RTSP provides an extensible framework to enable controlled, on-demand
delivery of real-time data, such as audio and video.  Sources of data can
include both live data feeds and stored clips.  This protocol is intended to
control multiple data delivery sessions, provide a means for choosing
delivery channels such as UDP, multicast UDP and TCP, and provide a means
for choosing delivery mechanisms based upon RTP (RFC 3550).

Working Group Summary

The document has been work in progress for an extended period of time
dating back to 2002. Earlier versions saw decent WG participation however
the later versions have primarily been driven by the document authors with
limited overall discussion in the group, especially towards the end of the
process. There are no known issues or major discussion points, and there has
been no indication of lack of consensus in the WG.

Document Quality

The document has been reviewed in detail several times after WGLC and in
preparation for the publication request and the authors have made several
updates as a result of those. The document is considered to be of high
quality at this point.

There is one known implementation of the specification, and many of the
extensions compared to RTSP 1.0 have been implemented separately as well.

A Media type review was done for "text/parameters". The review thread can
be found at: 
http://www.ietf.org/mail-archive/web/ietf-types/current/msg01656.html


Personnel
Document Shepherd: Flemming Andreasen
Responsible AD: Gonzalo Camarillo


RFC Editor's Note:

Section 2 of this document and its subsections provide "an informative
overview
of the different mechanisms in the RTSP 2.0 protocol, to give the reader a
high
level understanding".  As such, it's very important that it be clear and
well
written.  Some reviewers have found the English to be difficult.  Please
take
an especially critical pen to this section, making sure that the grammar
and
usage are correct, and that the language is clear.

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

--- End Message ---