Re: [ietf-types] Registration of media typeimage/svg+xml

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Thu, 25 November 2010 05:46 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: ietf-types@core3.amsl.com
Delivered-To: ietf-types@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AFA3A6A0C for <ietf-types@core3.amsl.com>; Wed, 24 Nov 2010 21:46:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.567
X-Spam-Level:
X-Spam-Status: No, score=-101.567 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Knwe82Oskv1I for <ietf-types@core3.amsl.com>; Wed, 24 Nov 2010 21:46:10 -0800 (PST)
Received: from pechora5.lax.icann.org (pechora5.icann.org [208.77.188.40]) by core3.amsl.com (Postfix) with ESMTP id 4DAEF3A6A21 for <ietf-types@ietf.org>; Wed, 24 Nov 2010 21:46:07 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by pechora5.lax.icann.org (8.13.8/8.13.8) with ESMTP id oAP5kWJR014259 for <ietf-types@iana.org>; Wed, 24 Nov 2010 21:46:53 -0800
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id oAP5kVd5024069 for <ietf-types@iana.org>; Thu, 25 Nov 2010 14:46:31 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 0b8e_2cdf_5a92b9be_f857_11df_a477_001d096c5782; Thu, 25 Nov 2010 14:46:30 +0900
Received: from [IPv6:::1] ([133.2.210.1]:40011) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S148FB56> for <ietf-types@iana.org> from <duerst@it.aoyama.ac.jp>; Thu, 25 Nov 2010 14:46:29 +0900
Message-ID: <4CEDF82A.7000502@it.aoyama.ac.jp>
Date: Thu, 25 Nov 2010 14:46:18 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Chris Lilley <chris@w3.org>
References: <1364503167.20100617162624@w3.org> <1715145489.20101118190255@w3.org> <1912120148.20101118235236@w3.org> <4CE60C77.6000601@it.aoyama.ac.jp> <C68CB012D9182D408CED7B884F441D4D04FADF4AF3@nambxv01a.corp.adobe.com> <701217612.20101124231612@w3.org>
In-Reply-To: <701217612.20101124231612@w3.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora5.lax.icann.org [208.77.188.40]); Wed, 24 Nov 2010 21:46:53 -0800 (PST)
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, "ietf-types@iana.org" <ietf-types@iana.org>, "ietf-xml-mime@imc.org" <ietf-xml-mime@imc.org>, Henri Sivonen <hsivonen@iki.fi>, Larry Masinter <masinter@adobe.com>
Subject: Re: [ietf-types] Registration of media typeimage/svg+xml
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-types>
List-Post: <mailto:ietf-types@ietf.org>
List-Help: <mailto:ietf-types-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-types>, <mailto:ietf-types-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Nov 2010 05:46:14 -0000

Hello Chris, Larry,

On 2010/11/25 7:16, Chris Lilley wrote:
>
> On Wednesday, November 24, 2010, 9:14:12 PM, Larry wrote:
>
> LM>  Martin, in a couple of places you complained that the SVG registration
> LM>  template, contained in a W3C document, referred to "this specification",
> LM>  and said:
>
> LM>  # "this specification" doesn't work when the registration template is
> LM>  # taken out of the SVG spec. Either say "the SVG specification" or
> LM>  # explicitly reference a specific version of the specification.
>
> LM>  However, I think it is common practice both in W3C and IETF, that
> LM>  a registration template embedded within another document can
> LM>  reasonably say "this specification" to mean the document in which
> LM>  it is embedded,

In that context, this looks reasonable, but out of context, it does no 
longer make sense. Registration are often taken out of context, and 
should be able to stand alone, without readers having to guess what "the 
specification" might be.

> LM>  with the registry itself pointing to an
> LM>  explicit version of the spec as well as the template within.

IANA often, if not always, lists the relevant RFC. But I haven't seen 
them listing other specifications. I may have missed it. Anyway, that's 
usually outside the registration, so the registration is still not 
standalone.

> Larry, your interjection is timely, as I was just about to edit the registration to address Martin's comment.
>
> Given that we already have
>
> Published specification:
>
>      This media type registration is extracted from Appendix P of the
>      SVG 1.1 specification. http://www.w3.org/TR/SVG/
>
> I'm tempted to just s/this specification/the published specification/

Great! That makes the registration standalone, while at the same time 
doesn't look weird inside the specification.

> LM>  There are plenty of examples... perhaps those comments don't apply?

The fact that there are plenty of examples doesn't mean that we can't 
fix it when we have a chance. I don't think it's worth doing back and 
fixing one by one, but if we are working on a registration anyway, we 
can make it better form the start.

> LM>  (This comment applies to all registries, not just of media types.)

Agreed.


Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp