Re: [ietf-types] Request for review of N-Triples (an RDF serialization) media type: application/n-triples

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Sun, 06 May 2012 06:21 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: ietf-types@ietfa.amsl.com
Delivered-To: ietf-types@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0011121F846F for <ietf-types@ietfa.amsl.com>; Sat, 5 May 2012 23:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.906
X-Spam-Level:
X-Spam-Status: No, score=-98.906 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, 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 RHvvGbM51vIy for <ietf-types@ietfa.amsl.com>; Sat, 5 May 2012 23:21:09 -0700 (PDT)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF9F21F8463 for <ietf-types@ietf.org>; Sat, 5 May 2012 23:21:08 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q466KvVd025056 for <ietf-types@ietf.org>; Sun, 6 May 2012 15:20:57 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2955_82fd_a48b7a56_9743_11e1_8e85_001d096c566a; Sun, 06 May 2012 15:20:57 +0900
Received: from [IPv6:::1] ([133.2.210.1]:37283) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S15C12F2> for <ietf-types@ietf.org> from <duerst@it.aoyama.ac.jp>; Sun, 6 May 2012 15:21:00 +0900
Message-ID: <4FA6183F.6030301@it.aoyama.ac.jp>
Date: Sun, 06 May 2012 15:20:47 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <20120418153629.GB29120@w3.org> <jv1bq71p3tgmoj47aqsilv9lfue88orvlt@hive.bjoern.hoehrmann.de>
In-Reply-To: <jv1bq71p3tgmoj47aqsilv9lfue88orvlt@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ietf-types@ietf.org
Subject: Re: [ietf-types] Request for review of N-Triples (an RDF serialization) media type: application/n-triples
X-BeenThere: ietf-types@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 06 May 2012 06:21:10 -0000

On 2012/05/06 5:10, Bjoern Hoehrmann wrote:
> * Eric Prud'hommeaux wrote:
>> Type name:
>>     application
>> Subtype name:
>>     n-triples
>> Required parameters:
>>     None
>> Optional parameters:
>>     None
>> Encoding considerations:
>>     The syntax of N-Triples is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [UTF-8].
>>     Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F]
>
> This is supposed to simply say something like "8bit" or "binary", see
> RFC 4288 for details.

I think it's actually very good to say that N-Triples are always in 
UTF-8 somewhere in the template. This could stay here, changing it e.g.
as follows:

The character encoding is always UTF-8. This media type therefore has to 
be transported as "8bit", or futher encoded for "7bit" transport.

>> Security considerations:
>
> I have not look at these, but since this is very long, it might make
> more sense to have this as part of the Security Considerations section
> of the document that defines the format, and simply put a reference
> into the template.
>
>> Published specification:
>>     This specification.
>
> As I recall it, unlike for RFC registrations, IANA would put this in
> a document on their site, so this should give a full(er) citation.

Yes, please make the registration template self-contained, even if that 
might look a bit like overkill when it's looked at in the spec.

Regards,   Martin.


> If you want to say anything about fragment identifiers, like what the
> `#example` in `http://example.org/example.nt#example` refers to, or
> if you want to discourage such usage, that should be included. Not a
> requirement currently, but since this is an RDF type, this might be
> relevant.