Re: I-D ACTION:draft-iesg-media-type-00.txt
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 05 July 2005 15:24 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DppHc-0006Rb-Ce; Tue, 05 Jul 2005 11:24:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DppHX-0006Lb-Dv; Tue, 05 Jul 2005 11:24:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09313; Tue, 5 Jul 2005 11:24:13 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dppd5-0000Md-Ps; Tue, 05 Jul 2005 11:46:37 -0400
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5B6264F0004; Tue, 5 Jul 2005 17:18:48 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 17:18:47 +0200
Received: from [147.214.34.71] ([147.214.34.71]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 17:18:47 +0200
Message-ID: <42CAA4D6.3080706@ericsson.com>
Date: Tue, 05 Jul 2005 17:18:46 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf@ietf.org
References: <46uajf$4f34l2@mx21.mrf.mail.rcn.net> <200507011536.49251.blilly@erols.com>
In-Reply-To: <200507011536.49251.blilly@erols.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Jul 2005 15:18:47.0084 (UTC) FILETIME=[D6DBB6C0:01C58174]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org
Subject: Re: I-D ACTION:draft-iesg-media-type-00.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Hi Bruce, I will comment some of the arguments that you list. And if we where having this discussion before any RTP payload name registry existed at all I would definitely be tempted by separated registries. However the fact that we have used an IETF established policy for more than 5 years and registered a large amount of names (>70) makes it very hard to see that moving into separated registries will resolve any confusion. In addition it will require a huge work effort to move to the new registry. I can also contest that AVT doesn't have a hoard of people interested in updating media types registrations. We can barely manage to perform updates of our own major RTP payload formats. When it comes to RTP payload formats there are always demand for new ones as new media codecs are defined, but the ones are already out-dated and sees less and less use there is little interest for. Especially to perform an exercise that provides no improvement. To me the best way forward is that we clean up the registration procedures of the current media types registry. Clearly document the fact that there are at least two different usages for the media types registry. It will help reduce the confusion that exist and have minimal workload. Bruce Lilly wrote: >> Date: 2005-07-01 11:38 >> From: Magnus Westerlund <magnus.westerlund@ericsson.com> >>Both in >>RTP and MIME usage the types are after all media formats with specified >>represenations. > > > That's a good reason to have registries which share certain > characteristics, but it does not require sharing the same > registry and namespace. The issue I see is that with two separate registries one will not seriously consider the names in the other registry. >>Having one registry with all representation instead of >>separating does not simplify the process of maintaining good usage of >>that registry and avoid duplicating entires when there actually are two >>different representations. > > > I'm not sure that I completely understand what you mean. Anyway: > Sorry for the bad sentence structure. What I intended to stress was that having cross review between registries is a hard way of avoiding having two different formats register the same name but in different registries. As the name structure looks the same, it is very hard to determine to which registry such a name would belong. Thus one needs to look up both if checking. I think having a single registry with clearly marked usage is a simplification. > If there is a single registry: > o each MIME and each RTP implementer will have to examine each entry > and determine: > * is this media type applicable to my work? > - yes > - no > - unclear > This is clearly more work for implementers if there is a combined > registry. To the extent that implementers ask questions ("what's > this 'framed' stuff?"), it may be more work for registered contacts > also. From my perspective a implementor normally know what it needs to support on a fundamental level. I need to support the AMR codec. From that perspective looking up audio/amr in either of the registries will be simple. In fact this is one of the media types that are both RTP and file format. This would need to be doubly registered and thus needs links to the other registry to have people avoid taking the wrong version if they are lacking the necessary knowledge. If the registry page would include columns that indicated usage of the media type this can easily be resolved. > o the registration procedures, forms, review forum, etc. will have > to accommodate items which are the union of items which are > individually applicable to different uses > * MIME registrants will continually ask "what is this 'framed' > encoding stuff?" > * RTP registrants will continually be told "your 'text' type > is incompatible with the requirements for 'no software required', > 'fallback to text/plain', etc." These reasons you list are due to the unclarity regarding the procedure. If one clears this up and makes it clear what is applicable and provide more concrete example then I don't think it will be a big problem. > These have been observed issues with use of the MIME registry for RTP What are you referring to. I don't think there has been any serious issues other than the ones that occur at registration time due to unclear process. That I think can be understood also by those registering for MIME usage only. > o if there is some media type that is usable by MIME and by RTP, it > need only be registered once (unless of course there are differences > in parameters, security issues, etc, in the registration form that > would indicate separate registration) > * the key question is, are there any such types? > - clearly you have said that, unlike MIME media types, the RTP > types cannot be stored in a file, etc. So it's clear that > the RTP types cannot be used by MIME > - can the MIME types be used by RTP? For example, can RTP make > use of the MIME media type application/vnd.ms-excel? > This would be a point in favor of a combined registry -- if and only > if there is a reasonable number of media types usable by both MIME > and RTP. I think this is one of the points of contentions in the earlier discussions we have had regarding this topic. This in the light of registrations like audio/amr (RFC 3267) that are for both file format and RTP. In my view the MIME and RTP usage can share huge parts of code, but they both needs some special adaptation. Me and Colin are not agreeing with Ned on what is considered required overlap between the RTP domain and MIME. > o if there are two types with incompatible definitions which wish > to use the same name, there will be a clash > * the namespace is big enough so that names aren't scarce > * however, there may be some user-land confusion, as sometimes > users infer more from a name that just it being a tag for something > This is a relatively minor point in favor of separate registries. > I agree that it is not a problem if we are capable of detecting and keeping the review to actually look in both registries and ensure that the other work is not trying to use the same name. > If there are separate registries: > o RTP implementers can look through an RTP registry, without having to > wade through MIME types and vice versa. Likewise for any other > registries that might be desirable > * MIME implementers can safely ignore the RTP registry and vice versa > - any implementer who needs to be concerned with both can of course > look at both > Point in favor of separate registries. I can agree with that if one comes looking at names from that direction. However I think the most common is that one either comes from the defining RFC or have the type name and want to look it up. In these cases separate registries do not provide any benefit. This only exist if you have the task of implementing all relevant audio/ types. > o registration procedures, forms, review forums, etc. can be customized > for the particular needs, simplifying matters for registrants, reviewers > (including the IESG), and IANA (e.g. if one registry needs a way to > an "obsolete" status and others do not, there is no conflict in > information presentation) > * reduces the number of questions/potential for confusion among > - registrants > - reviewers (including IETF Last Calls if issued, IESG) > - implementers > Point in favor of separate registries However the will actually be an increase in questions as you will also need to ask: Are this name registered in the other registry? If yes, is this a type that are the same or should it use another name? > o if there is some media type which is usable by both MIME and RTP, > registration would have to be duplicated (modulo differences in forms > and so on) > * as above, are there any? > * copy and paste... > * maybe some incremental work for IESG and IANA -- *IF* there are any > such types > Point in favor of a combined registry, if and only if there is a > reasonable number of such combined-use media types There are 5 or so that are combined registered. > o no clashes in the case of incompatible definitions, even if similar or > the same name is used, provided that MIME and RTP do not interact in > such a way as might cause confusion about whether media is a MIME > type or an RTP type > * as I understand it, there is no opportunity for confusion; any > relationship would require some sort of conversion, and a software > or protocol entity accepts/generates either one type or the other > * names in each realm can be convenient for users, though there may > be some potential for user confusion about whether a type is a MIME > type or an RTP type > Point in favor of separate registries. The confusion on this level do exist more in the head of implementors and users. Looking at the name audio/amr can you determine what registry it belongs in? And the answer is no, you need to have the application context to determine that. I think the work of educating these people is the same independent of one or several registries. > > Issues which might be unclear: > o Expert reviewer/review forum workload > * clearly there is a flow of MIME registrations; it also appears that > there is a flow of RTP registrations > - Is the combined total too much for one reviewer/one review forum? > - Is there enough flow of both types to support two reviewers (reviews > happen frequently enough that the reviewer hasn't retired or moved > on between reviews)? > - if the answers are: > yes/no -- inconsistent > yes/yes -- indicates in favor of separate registries > no/no -- use one reviewer (doesn't matter if registries are combined > or separate) > no/yes -- indicates in favor of separate registries > Either inconclusive or favors separate review forums (and registries, to > avoid clashes). I agree with the concern these question raises. However from my perspective there will be need to have cross review between the different domains. Thus having two review forums will only result in need for coordination. > o Expert reviewer/review forum expertise: > * I believe that past discussion on the media types review list and here > indicates that while reviewers are familiar with MIME issues, RTP > issues have not always been well-understood. While we can learn/adapt, > separate review forums, possibly also separate reviewers might be > more productive for all parties > Seems to favor separate review forums, probably separate registries (to > avoid clashes) I think that we need reviewers that learn to understand both issues. Also that appointed reviewers belong to both sides to ensure correct review. > > As I see it, most of the issues seem to favor separate registries, the > exception hinging on whether or not there are any media types which are > usable by both MIME and RTP. If I understand the bulk of your message > correctly (which is similar to explanations made on the media types > review list some weeks ago), there aren't any. > There are at least 5 types that are both RTP payload formats and file formats. They are all having the same smallest unit that the codec handles. The difference between RTP and files are that RTP uses explicit timing while the files are using implicit by the order the data is stored. Small variations in packetization do also occur and in most cases there are also an magic word starting the file. There are a lot of pro and con and I don't see a lot of decisive arguments. Therefore I would like to point out the issue of workload. I think we should select the way forward that results in least work why still improves the situation. To me that is to keep a single registry and improve the registration process and information. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: I-D ACTION:draft-iesg-media-type-00.txt Bruce Lilly
- Re: I-D ACTION:draft-iesg-media-type-00.txt Colin Perkins
- Re: I-D ACTION:draft-iesg-media-type-00.txt Robert Elz
- Re: I-D ACTION:draft-iesg-media-type-00.txt Colin Perkins
- Re: I-D ACTION:draft-iesg-media-type-00.txt Magnus Westerlund
- Re: I-D ACTION:draft-iesg-media-type-00.txt Robert Elz
- Re: I-D ACTION:draft-iesg-media-type-00.txt Robert Elz
- Re: I-D ACTION:draft-iesg-media-type-00.txt Stephen Casner
- Re: I-D ACTION:draft-iesg-media-type-00.txt Bruce Lilly
- Re: I-D ACTION:draft-iesg-media-type-00.txt Bruce Lilly
- Re: I-D ACTION:draft-iesg-media-type-00.txt Colin Perkins
- Re: I-D ACTION:draft-iesg-media-type-00.txt Magnus Westerlund
- Re: I-D ACTION:draft-iesg-media-type-00.txt Magnus Westerlund