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

[Ned Freed <[e-mail]>]

> > 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.

> 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.

> > >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.
> >
> > 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

> 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.