Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 23 August 2013 13:53 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CA911E817A; Fri, 23 Aug 2013 06:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.673
X-Spam-Level:
X-Spam-Status: No, score=-103.673 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_15=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYp7vYN7diGQ; Fri, 23 Aug 2013 06:53:43 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7B08211E81A4; Fri, 23 Aug 2013 06:53:42 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-46-5217696389fb
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id D8.D9.25272.36967125; Fri, 23 Aug 2013 15:53:39 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.20) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.328.9; Fri, 23 Aug 2013 15:53:38 +0200
Message-ID: <52176998.5000101@ericsson.com>
Date: Fri, 23 Aug 2013 15:54:32 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Elwyn Davies <elwynd@folly.org.uk>
References: <1370477514.4596.9052.camel@mightyatom> <51C85D02.1050907@ericsson.com> <1372164466.4524.9526.camel@mightyatom>
In-Reply-To: <1372164466.4524.9526.camel@mightyatom>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+JvjW5ypniQwa/TohYXvxxhtzh+YAe7 xdVXn1kspi5/zOLA4vH1ZDuLx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CVsXHLJKaCnWkV e3+sZm5gbA7oYuTkkBAwkfg1s4cRwhaTuHBvPVsXIxeHkMBRRonDs0+wQzjLGCVWzNjPClLF K6At0b5iAwuIzSKgKjHn2XF2EJtNwELi5o9GNhBbVCBYon37VzaIekGJkzOfgNWLCKhJbP76 gBFkKLNAN6PE7GcXmEASwgJhEvO2dIPZQgI1Es9a7oAN5QQ6b/2aJhaI8yQlti06BhZnFtCT mHK1hRHClpdo3jqbGaJXW6KhqYN1AqPQLCS7ZyFpmYWkZQEj8ypGjuLU4qTcdCODTYzAcD64 5bfFDsbLf20OMUpzsCiJ827ROxMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVEna7bC54Pi b1ie1RdNKL/OtkpqJcsyVXf2t3qnN8/lZvZNmtqs9Xfqc8cFBjv2LznMyPnuUPv0WeqKTc85 jy9Vsq7aHdy0emWf6NZL8VWXf4dldUw/lm0XL5bnJXh2tp1vj0oXh51cTfmPXdJ7bfQLpW2b 7997HhHOblv2NWX95CDG/vZ7skosxRmJhlrMRcWJALC5bf81AgAA
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org, "mmusic (E-mail)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2013 13:53:49 -0000
Hi, Now getting to implement your response in our source. Some few additional comments or notes below. On 2013-06-25 14:47, Elwyn Davies wrote: > > On Mon, 2013-06-24 at 16:51 +0200, Magnus Westerlund wrote: >> Elwyn, >> >> Follow up on some of the nits that is not simply to implement or where I >> disagree or want to provide feedback. >> >> This email covers all issues up to and including Section 11. That is as >> far as I have managed to process them yet. I will now handle over the >> rest of this list to my co-authors. >> >> On 2013-06-06 02:11, Elwyn Davies wrote: >>> >>> >>> ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified >>> values "smpte", "npt" and "clock" are valid in the Range parameter. >>> What is the meaning of such an unqualified value? >> >> You are correct about that the basic definition in ABNF allows for >> empty. The reason for this is the following stated in Section 18.38: >> >> It MAY be >> included in GET_PARAMETER requests from the client to the server with >> only a Range format and no value to request the current media >> position, whether the session is in Play or Ready state in the >> included format. >> > Two points: > - A suggestion: Make ss4.4/4.5/4.6 into subsections of a new s4.4. Add > a bit of text in the new s4.4 saying that the range specifiers are used > in the RANGE header and pointing to s18.38 for the unqualified use. > (consistent with s2.7 which gives usage). > - An issue I hadn't spotted: I haven't checked but are the unqualified > values allowed in the SDP extension case (s20.3)? >> >> I think your suggestion is a good one and I have written such a section, initial proposal below: 4.4. Media Time Formats RTSP currently supports three different media time formats defined below. Additional time formats may be specified in the future. These time formats can be used with the Range header (Section 18.38) to request playback and specify at which media position protocol requests actually will or has taken place. They are also used in description of the media's properties using the Media-Range header (Section 18.29). The format identifier only are used in Accept- Ranges header (Section 18.5) to declare supported time formats and also in the Range header (Section 18.38) to request the time format used in the response. 4.4.1. SMPTE Relative Timestamps Regarding the SDP a=range attribute. The ABNF allows the unqualified usage. The textual specification of a=range attribute in D.1.6 is silent on unqualified usage. The only usage of unqualified usage in a=range would be to indicate that although this media has unknown or time-progressing properties it does support the time formats for the a=range with unqualified values that has been included. >> >>> >>> s10.2, para 6 and following note: I can't see that the note following >>> para 6 can be justified: since the restriction on multiple connections >>> from a client to a server is only a SHOULD, an interoperable server MUST >>> be capable of handling multiple connections from a client unless the >>> server can explicitly send back a TOO MANY CONNECTIONS status. >> >> See separate email > > Should I have had this already? It was sent to the MMUSIC WG mailing list on the 24th of June. I have forwarded if to you personally. > >> >>> >>> s10.6: RFC 3986 has capability for dealing with IP versions beyond 6... >>> should these be carried over into RTSP? The IANA registry says they are. >> >> I am uncertain what you want here? Yes, the URI format allows for future >> definitions of literal IP address versions. However, RTSP does contain >> explicit IPv4 and IPv6 address fields that aren't URIs. Thus, future IP >> versions will require some extension definition to function. > > Perhaps an excess of zeal on my behalf. Perhaps a (non-normative) note > saying what you just wrote: 'Although the general URI format envisages > potential future new versions of the literal IP address, usage of any > such new version would require other modifications to the RTSP > specofication (e.g., ...[any relevant section(s)]).' Yes, I added such text. >> >>> >>> s10.7, last para: Should the doubling of the wait timer have an upper limit? >> >> Yes, I added an upper limit of 30 minutes. This is way beyond what any >> human will accept, only robots will keep on going at this timeout value. >> And I think that is large enough to avoid any issues. > > Agreed > >> >> I also propose to clarify the range for the variations and added the >> classical 0.5 to 1.5 times the deterministic value. >> >> Text proposal. >> >> That timer MUST be doubled for each additional failure to connect or >> receive response until the value exceeds 30 minutes when the timers >> deterministic value may be set to 30 minutes. It is RECOMMENDED to not > ^^^^^^^^^^^^^ > base? >> set the same value in the timer for each scheduling, but instead to add >> a variation to the mean value, resulting in picking a random value >> within the range of 0.5 to 1.5 of the mean value. This has gotten changed a bit more and currently reads: A more complex case may arise when a load balancing RTSP proxy is in use, i.e., where an RTSP proxy is used to select amongst a set of RTSP servers to handle the requests, or when multiple server addresses are available for a given server name. The proxy or client may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) from one of its RTSP servers or proxies, or a TCP timeout (if the server is even unable to handle the request message). The proxy or client simply retries the other addresses or configured proxies, but may also receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) response or TCP timeouts from those addresses. In such a situation, where none of the RTSP servers/proxies/addresses can handle the request, the RTSP agent has to wait before it can send any new requests to the RTSP server. Any additional request to a specific address MUST be delayed according to the Retry-After headers received. For addresses where no response was received or TCP timeout occurred, an initial wait timer SHOULD be set to 5 seconds. That timer MUST be doubled for each additional failure to connect or receive response until the value exceeds 30 minutes when the timers mean value may be set to 30 minutes. It is REQUIRED to not set the same value in the timer for each scheduling, but instead to add a variation to the mean value, resulting in picking a random value within the range of 0.5 to 1.5 of the mean value. >> >>> >>> s11, para 4: According to s22.1.3, play.basic, play.scale and play.speed >>> are 'defined' in this draft. The nearest thing to a definition of >>> play.basic that I can find is the last sentence of para 4 in this >>> section. I am not convinced that I could produce an interoperable >>> implementation of a server with this feature-tag with the one sentence >>> 'definition'. References to where play.xxx are defined would be useful >>> (play.scale in s18.44, play.speed in s18.48). >>> >> >> Hmmm, the other feature-tags than play.basic are pretty straightforward >> and well contained. play-basic is really a minimal RTSP server >> implementation according to the whole spec for media playback. >> >> This can probably be more clearly expressed somewhere, but it can't >> really be enumerated. Then we are back to the issue we had with RFC 2326 >> minimal implementation list that was incomplete and lacked a lot of >> things really necessary. >> >> This issue still haven't resulted in any changes to our source. > > Ah! I see I have (re-)opened a can of worms! One thought for providing > the proverbial larger can into which the worms can be stuffed back: > > Define 'play.basic' as the default that you get back if none of the > others apply. How's that for weasel words! After my leave I have written a bit of definition for play.basic: 11.1. Feature Tag: play.basic The play.basic feature tag represents an RTSP implementation according to all normative RTSP protocol features specified in this specification. This specification is both a RTSP core specification as well intended to enable setup and control of playback of media. Thus following all normative parts in the main sections (the ones with numbers), not the appendices (starting with letters), unless explicitly specified in a main section for being a required appendix. Note: This feature tag does not mandate any media delivery protocol, such as RTP. In RTSP 1.0 there was a minimal implementation section. However, that was not consistent with the rest of the specification. So rather than making an attempt to explicitly enumerate the features for play.basic this specification have to be read in completeness and the necessary features normatively defined as being required are included. >> >> >>> s11, Supported (and Proxy-Supported) bullets: >>> OLD: >>> This results in the >>> receiver is learning the requester's feature support. >>> NEW: >>> This results in the >>> receiver learning the requester's feature support >>> relevant to the specified resource. >>> [Note: I added 'specified resource' here and then thought about whether >>> this made any sense. It probably needs to be clearer what set of >>> features are included in the Supported list for both requester and >>> responder. Are they restricted to those relevant to the specified >>> resource that might of course be the whole server, proxy - or client?? - >>> in which case there isn't an issue, but it might be a specific >>> presentation - what happens then? Affects s13.1, para 3 also.] >> >> Actually, I don't think it is specific to the media resource. The issue >> with making it specific to a media resource is that a RTSP client needs >> to be able to look into the future and supply an answer for a media >> resource it may not yet know sufficient to provide a tailored response >> for. I think it is simpler and better to provide general capabilities in >> the supported header and then later determine how well they apply for >> the media resource itself. > > So maybe make it clear that feature support returned is just what the > responder can do generally and is not specific to the URI provided. Yes, I have tried to make it clear that it is not resource specific. Supported: This header is used to determine the complete set of functionality that both client and server have in general and is not dependent on specific resource. The intended usage is to determine before one needs to use a functionality that it is supported. It can be used in any method, but OPTIONS is the most suitable one as it at the same time determines all methods that are implemented. When sending a request the requester declares all its capabilities by including all supported feature-tags. This results in the receiver is learning the requester's feature support. The receiver then includes its set of features in the response. Proxy-Supported: This header is used similarly to the Supported header, but instead of giving the supported functionality of the client or server it provides both the requester and the responder a view of the common functionality supported in general by all members of the proxy chain between the two supports and not dependent on the resource. Proxies are required to add this header whenever the Supported header is present, but proxies may also add it independently of the requester. I also added variations of this sentence to the Supported and Proxy-Supported headers description: These feature tags are the ones the server or client support in general, and is not specific to the request resource. > > Either that or make the request valid only for non-specific URIs (i.e. > at the server/client level) if that is possible (not sure how that would > work for server asking client if that is allowed). Doesn't really work as supported is intended to be possible to add to any request to determine the functionality supported by the replying agent. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- Re: [MMUSIC] Gen-art additional LC review of draf… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Elwyn Davies
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Elwyn Davies
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Magnus Westerlund
- Re: [MMUSIC] Gen-art additional LC review of draf… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Elwyn Davies
- Re: [MMUSIC] Gen-art additional LC review of draf… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Magnus Westerlund
- [MMUSIC] RTSP 2.0: Body format negotiation Magnus Westerlund