Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt
Ned Freed <ned.freed@mrochek.com> Sat, 04 February 2012 07:23 UTC
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68EA21F8534 for <apps-discuss@ietfa.amsl.com>; Fri, 3 Feb 2012 23:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6]
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 oRZhyYpl7KxB for <apps-discuss@ietfa.amsl.com>; Fri, 3 Feb 2012 23:23:54 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id AE2DF21F853F for <apps-discuss@ietf.org>; Fri, 3 Feb 2012 23:23:53 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBKKTRJ5PS00TK8L@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 3 Feb 2012 23:23:52 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OBHM72OXPS00ZUIL@mauve.mrochek.com>; Fri, 3 Feb 2012 23:23:49 -0800 (PST)
Message-id: <01OBKKTPYLIE00ZUIL@mauve.mrochek.com>
Date: Fri, 03 Feb 2012 22:52:03 -0800
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sat, 04 Feb 2012 07:38:23 +0200" <CADBvc9_W9Jaca1TmV5QjyXupLVyLJh=6+334p-HM5pB=aKn15w@mail.gmail.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <20120204001408.16716.94710.idtracker@ietfa.amsl.com> <CADBvc9_W9Jaca1TmV5QjyXupLVyLJh=6+334p-HM5pB=aKn15w@mail.gmail.com>
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Feb 2012 07:23:54 -0000
> Hi all, > Looking through this document again... > I don't really know whether comments from > http://www.ietf.org/mail-archive/web/happiana/current/msg00184.html have > been considered (at least, no response from authors have been received so > far), but here is what I see in the current version with respect to the > issues these comments concerned: Yes, I did take them into consideration. > --citing begins (my comments in-line starting with "MY>")-- > Ned, all, > Some additional (to Julian's) comments. > In Abstract, it must be mentioned that the document obsoletes RFC 4288. A stupid rule in my opinion, but a rule nevertheless. I forgot to add it but will do so in the next revision. > MY> Still relevant. > I find the current text in Introduction very confusing (or irrelevant), as > it is very generic and not related to media types. It should be rewritten > to make clear the goal of the doc. I also concur with Julian that > Historical Note should be moved in the Introduction section. > MY> Now Introduction seems fine. I actually didn't change anything in response to your comment because I couldn't figure out how to do so, so I'm a little confused as to why you think it's OK now but not before, but as you think it's OK now I guess it's all good. > In Section 3.1: when specifying the procedures for registration media types > in Standards Tree, you mentioned (in terms of RFC 5226): IESG approval, > Specification Required, IETF Consensus, RFC Required with IESG Approval, > i.e. 4 different registration policies. Whereas they serve a variety of > possible cases, I think we would benefit from a single policy which would > cover all of them. I suppose it is "Specification Required with IESG > Approval" that would cover the following cases: (1) IESG-approved document, > (2) specification of other standards body; registration undergoing IESG > approval, (3) non-IESG-approved RFCs, registration of which also undergo > IESG approval. The possible cases may also be discussed, though. > MY> Also relevant in this version. If I understand what you're trying to do, not going to happen. The main point of this revision is to remove the need for the IESG to be involved in the approval of standards tree types from other SDOs, while retaining their role in IETF registration approval. As such, your suggestion for a single policy for all registrations is totally inconsistent with the fundamental goal of this revision. > Section 3.3: the "vanity" naming. I may be wrong cause it may be some sort > of stylistic choice, but I actually think that "personal" is enough to > characterize this tree. Whereas English native speakers would understand > such naming, this would be frankly difficult for those who speak English as > a foreign lang. I can't manage to find Russian or Ukrainian translation of > RFC 4288 to prove, but I'm sure that the said formulation is applicable in > English language only, and isn't appropriate for the international-scoped > document. > MY> Relevant as well. I'm sorry, but I really don't see the point of removing it. It's not like it has ever proved to be a source of confusion in the past. > Section 3.4: this is what Julian has already mentioned for Section 4.2. > APPSAWG is obliged to bring the draft deprecating x- to BCP, so if we > revising the procedures docs, we need to take it into account. I propose > you remove Section 3.4 and naming convention from Section 4.2 but put a > note in Appendix B referring to the RFC-to-be. <later when="after reading > reply to Julian's message">I think that if we produce new version of the > doc we should take into account the current practice documented as BCP (and > I hope it will get BCP). At least you should note that their registration > is not absolutely prohibited; I also agree that in exceptional cases they > can be registered, but only if wide use is demonstrated.</later> First of all, the WG is in no way "obliged" to do anything. It may in fact fail to reach consensus and not do anything about x-. The draft in question is still being actively debated, and there appears to be some controversy. I'm waiting to see the outcome of that before taking any action on this point, as it's possible the whole x- thing may prove to be a lot more problematic than some suppose. > MY> Current WG draft on deprecating x- says nothing on this, so I think we > still should mention something in this document. Let'as consider my above > proposal. I was thinking of going further and saying something like "the restriction on registration of x- types that appeared in previous document has been dropped" or something along those lines, but I really want to wait. > Section 4.2: Shouldn't it explain the differences between RFC 2045 and the > given ABNF? Nope. I very intentionally chose not to get into the historical details of why the restrictions exist. This is a document focused on getting registrations done. The origin of the restrictions or comparisons to what they were historically do not assist in that goal in any way that I can see. > Section 4.10: "Proposals for media types registered in the standards tree > by the IETF itself MUST be published as RFCs.". Do you really mean > "proposal"? Also, do we need to encourage publishing RFCs for vnd and prs > registrations? > MY> This is ok in the current version. I agree and not only that, I removed the word "proposal" in several other places as well in response to your comment. (There's still one left that I believe is necessary - I took it out but was convinced it needed to go back in.) > Section 5.1: "Registrations in other trees MAY be sent to the list for > review as well." Maybe SHOULD? > MY> Fixed; thanks. > Section 5.9: Do we need to leave mail-style lines in the template (I mean > To: and Subject:)? > MY> (Now s5.7), and fixed in the doc. Yeah, it was unnecessary. > Ibid: Please move the para about MacOS file types into Section 4.11. > MY> Now moved, I see. Actually, no, I didn't move the pointer to the reference out of the template, and I should have. This is now sufficiently obscure that having it in the template is a distraction. (Again, focus focus focus on getting registrations done with as few distractions as possible.) I'll move it. > Section 6: s/RFC 3978/RFC 5378/ (and in References) > MY> This is fixed. > Sections 6 and 8: As your document sets up the registry for +suffixes, it > should contain the description as required by RFC 5226, which it currently > doesn't have. > MY> This comment still applies. Description where? I do not understand this one. I also do not see the requirement you're talking about anywhere in RFC 5226. (The word description appears exactly twice, and neither time in a requirement.) > --citing ends-- You might want to look at the open issues list and consider if they are good ideas or not. Ned
- [apps-discuss] I-D Action: draft-ietf-appsawg-med… internet-drafts
- Re: [apps-discuss] I-D Action: draft-ietf-appsawg… Mykyta Yevstifeyev
- Re: [apps-discuss] I-D Action: draft-ietf-appsawg… Ned Freed
- [apps-discuss] Requirement for "obsoletes" in Abs… John C Klensin
- Re: [apps-discuss] I-D Action: draft-ietf-appsawg… John C Klensin
- Re: [apps-discuss] I-D Action: draft-ietf-appsawg… Mykyta Yevstifeyev
- Re: [apps-discuss] I-D Action: draft-ietf-appsawg… Mykyta Yevstifeyev
- Re: [apps-discuss] I-D Action: draft-ietf-appsawg… Ned Freed
- Re: [apps-discuss] Requirement for "obsoletes" in… Ned Freed
- Re: [apps-discuss] Requirement for "obsoletes" in… Barry Leiba
- Re: [apps-discuss] Requirement for "obsoletes" in… Roy T. Fielding
- Re: [apps-discuss] Requirement for "obsoletes" in… John C Klensin
- Re: [apps-discuss] Requirement for "obsoletes" in… Roy T. Fielding
- Re: [apps-discuss] Requirement for "obsoletes" in… Julian Reschke
- Re: [apps-discuss] Requirement for "obsoletes" in… Julian Reschke
- Re: [apps-discuss] Requirement for "obsoletes" in… John C Klensin
- Re: [apps-discuss] Requirement for "obsoletes" in… Dave CROCKER
- Re: [apps-discuss] Requirement for "obsoletes" in… Barry Leiba
- Re: [apps-discuss] Requirement for "obsoletes" in… Paul Hoffman
- Re: [apps-discuss] Requirement for "obsoletes" in… Julian Reschke
- Re: [apps-discuss] Requirement for "obsoletes" in… John C Klensin
- Re: [apps-discuss] Requirement for "obsoletes" in… SM
- Re: [apps-discuss] Requirement for "obsoletes" in… Dave CROCKER
- Re: [apps-discuss] Requirement for "obsoletes" in… Ned Freed
- Re: [apps-discuss] Requirement for "obsoletes" in… Dave CROCKER
- Re: [apps-discuss] Requirement for "obsoletes" in… Ned Freed