Subject: [ietf-types] Update on the pending registration of text/n3

From: Nathan <[email-masked]>
Date: Wed, 26 Jan 2011 01:57:28 +0000

Hi,

I've been asked to find out about the registration of the 'text/n3' 
media type, relating to Notation3 [1,2]. To quote from the annotated 
design issue [2]:

   """The type application/n3 was applied for in 2002 and again in 
2006. The IETF-W3C liaison meeting established that the mime type 
would be formally awarded when the N3 specification was in a 
'published' form. In the mean time, it should be used as part of the 
point of N3 is to be human readable, and so the text tree is 
indicated. The application for text/rdf+n3 with the IANA registry is 
pending as of 2006-02 as IANA #5004. There was an agreement to change 
it to text/n3 as the rdf+ idea met with significant criticism. While 
registration is pending, applications should use the proposed type in 
anticipation of registration, not an x- type."""

The specification is now 'solid', and has been for a considerable 
time, further:

- There are many implementations which have been made over the 10 years
- There is a significant amount of Notation3 data available on the web 
and in use
- There is significant reluctance to further deploy Notation3 data 
based PURELY on the lack of MIME registration.
- There is still a lot of confusion as to what the content-type is (as 
no media type is registered)
- There is no entry in the default Apache mime.types file, so serving 
and negotiating these files is more difficult.

Consequently, can you give either myself or Tim Berners-Lee (cc-d) an 
update on the pending application, or inform us as to the best course 
of action in order to get the 'text/n3' media type registered in a 
timely fashion.

Best,

Nathan

[1] http://www.w3.org/TeamSubmission/n3/
[2] http://www.w3.org/DesignIssues/Notation3

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 26 Jan 2011 15:25:59 +0900

Hello Nathan, others,

I suggest you have a look at 
http://www.w3.org/2002/06/registering-mediatype. It may be that not 
everything on that page can be applied directly, but I hope it still helps.

Regards,   Martin.

On 2011/01/26 10:57, Nathan wrote:
> """The type application/n3 was applied for in 2002 and again in 2006.
> The IETF-W3C liaison meeting established that the mime type would be
> formally awarded when the N3 specification was in a 'published' form. In
> the mean time, it should be used as part of the point of N3 is to be
> human readable, and so the text tree is indicated. The application for
> text/rdf+n3 with the IANA registry is pending as of 2006-02 as IANA
> #5004. There was an agreement to change it to text/n3 as the rdf+ idea
> met with significant criticism. While registration is pending,
> applications should use the proposed type in anticipation of
> registration, not an x- type."""
>
> The specification is now 'solid', and has been for a considerable time,
> further:
>
> - There is significant reluctance to further deploy Notation3 data based
> PURELY on the lack of MIME registration.
> update on the pending application, or inform us as to the best course of
> action in order to get the 'text/n3' media type registered in a timely
> fashion.
>
> Best,
>
> Nathan
>
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Ned Freed <[email-masked]>
Date: Tue, 25 Jan 2011 22:29:14 -0800 (PST)

> media type, relating to Notation3 [1,2]. To quote from the annotated

First and foremost, the lack of an explicit facet in the name means this is a
standards tree registration (which certainly seems appropriate for this type).
Standards tree registrations are supposed to be reviewed on this list, but
approval of them is the province of the IESG. (See RFC 4288 section 5 for
details.) So the appropriate thing to do is (1) Post the media type
registration form to this list for review, (2) Deal with any review comments,
and (3) Submit the registration to the IESG for final review and approval.

> indicated.

I note that there appears to be a contradiction here - the type is named
application/n3 but this then talks about it being text/n3.

In any case, I will point out that the text tree has restrictions besides being
"human readable" - specifically, there's a requirment that line breaks be
represented by CRLF sequences that precludes the use of charsets like UTF-16. I
don't know if this is an issue for this type or not, but if it is you're better
off staying in the application tree.

> The application for text/rdf+n3 with the IANA registry is
> it to text/n3 as the rdf+ idea met with significant criticism.

In regards to the "pending" registration, it appears to have been submitted to
IANA on 30-Jan-2006 (for text/rdf+n3). It was forwarded to me for review on
3-Mar-2006. I responded on 6-Mar-2006 saying that (a) Since this is a standards
tree registration it needed to go to the IESG and (b) The fact that no security
considerations were provided was unlikely to be acceptable to the IESG. I
assume that IANA responded with my comments to the submitter at that time. I
don't know if IANA then closed the request, but if they didn't they should have
since IANA cannot register types in the standards tree.

I note that tHere may also be an issue with the + - we reserve +suffixes as a
indicator that the type is in a particular format, e.g. +xml. I don't know if
n3 qualifies in this fashion. That said, there would be no problem from a
process perspective using rdf-n3. Whether that's more appropriate than n3 is
really the W3C's call to make.

> While

Always a good idea.

> The specification is now 'solid', and has been for a considerable

OK.

> based PURELY on the lack of MIME registration.

Then let's by all means get the registration done.

> of action in order to get the 'text/n3' media type registered in a

See above for my recomendations as to the next steps to take.

---

From: Ned Freed <[email-masked]>
Date: Wed, 26 Jan 2011 14:30:38 -0800 (PST)

> N3 and Turtle are UTF-8 formats (most at present being within us-ascii);
> would it suffice to add text like:?
>   As the text media tree requires line breaks to be expressed as 0x0d 0x0a,
>   all occurances of 0x0d not followed by 0x0a and all occurances of 0x0a
>   not preceeded by 0x0d are replaced by 0x0d 0x0a.
> I've attached a sample registration with this text added.

I'm not sure such text is required, but it can't hurt.

> I also had the impression that the CRLF restriction doesn't reflect
> current practice (trying "line1\nline2\n" in several mail clients and
> browsers) and that it was on the HTTP WG's agenda to relax that constraint.
> In this case, such text would seem unnecessary.

It's one thing to use bare CRs and LFs in place of CRLFs. That will often
work, although there are also cases where it won't. But if you try this
with actual UTF-16 text, the odds are good that it will fail, and moreover
it can fail in ways that end up completely corrupting the content. But this
appears to be a nonissue given you're using utf-8.

> Ned, do you think it would suffice for Nathan to use the Security
> considerations from http://www.w3.org/2010/01/Turtle/#sec-mediaReg ?
> It references IRI and URI considerations and has a paragraph about
> phishing (which I'd like to be useful in other registrations).

First, I'll again note that I'm not the approver here, the IESG is. So the best
I can do is tell you what I'd be looking for if I were the approver.

With that caveat, I'd say that those considerations are great but not
sufficient. The things I look for this section to do are to:

(1) State whether or not the media type contains active or executable
    content. If the media type does contain executable content explain
    what measures have been taken to insure that it can be executed
    safely, e.g. a sandbox, safe operation set, signed content, etc.

(2) State whether or not the information contained in the media type
    needs privacy or integrity services.

(3) If the answer to (2) is yes, elaborate on any privacy or integrity
    services the media type itself provides.

Other considerations like the ones you cite are of course welcome.

				Ned

P.S. Maybe I screwed up and missed it somehow, but I don't think you included a
template in your response.