Subject: Re: [ietf-types] Q's regarding development of +json media types
From: mike amundsen <[email-masked]>
To: Sandro Hawke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Fri, 1 Oct 2010 00:58:09 -0400
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

<snip>
> It seems like there's no name he can use when starting out that will
> continue to be sensible years down the road, if the type becomes widely
> adopted, perhaps being blessed by a standards body.  Is that the state
> of the art, that you just have to plan to change the media type at some
> point?
</snip>

Yes, AFAIK, that is correct. If you want it blessed by the standards
body, you need to use a name in the standards tree and go through the
standards process.

While I can't speak from experience (surely there are others on this
list who can), I suspect a valid pattern to follow is to register a
"prs" or "vnd" media type id (as appropriate to your circumstance) and
then, as things get popular, adopt a new standards-level media type id
and register that one separately.

This process will result in two media types, one of which can
eventually be deemed "Obsolete [2] (since registered types cannot be
deleted).

FWIW, I left out the doc's reference to the "x." and "x-" facets[1]
which might appeal to some despite the "discouragement" voiced in the
doc. I've seen new media types adopted using this "x" pattern by both
persons and vendors.

[1] http://tools.ietf.org/html/rfc4288#section-3.4
[2] http://tools.ietf.org/html/rfc4288#section-10

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

#RESTFest 2010
http://rest-fest.googlecode.com

On Fri, Oct 1, 2010 at 00:13, Sandro Hawke <[email-masked]> wrote:
> On Thu, 2010-09-30 at 16:40 -0400, mike amundsen wrote:
>> Experimental types should use the "prs" facet[1].
>>
>> Vendor-specific types (non experimental, etc.) should use the "vnd" facet[2].
>>
>> [1] http://tools.ietf.org/html/rfc4288#section-3.3
>> [2] http://tools.ietf.org/html/rfc4288#section-3.2
>
> Thanks for the pointer, and perhaps I'm being dense, but I still don't
> see what subtree a developer, like Nathan, who is in the early stages of
> potentially creating a standard should use.  It seems wrong to use vnd,
> since he's not a vendor and (at least in this hypothetical) has no
> intention of ever creating a product here, commercial or otherwise.  It
> seems wrong to use prs, since that would associate the media type
> forever with him, even though he might lose interest in a year, while a
> community processes takes it over.
>
> It seems like there's no name he can use when starting out that will
> continue to be sensible years down the road, if the type becomes widely
> adopted, perhaps being blessed by a standards body.  Is that the state
> of the art, that you just have to plan to change the media type at some
> point?
>
>    -- Sandro
>
>> mca
>> http://amundsen.com/blog/
>> http://twitter.com@mamund
>> http://mamund.com/foaf.rdf#me
>>
>>
>> #RESTFest 2010
>> http://rest-fest.googlecode.com
>>
>>
>>
>>
>> On Thu, Sep 30, 2010 at 16:32, Sandro Hawke <[email-masked]> wrote:
>> > On Thu, 2010-09-30 at 16:23 -0400, Gregg Kellogg wrote:
>> >> I don't think it makes sense to describe JSON serializations of Notation 3 or N-Triples, as these are themselves just serializations of RDF. Perhaps what you're describing is two different JSON serializations of RDF, one which is more closely related to Notation-3 and the other N-Triples. Although, note that Notation-3 is, itself, a super-set of N-Triples (as is Turtle [1]), so is there really a requirement for two different serializations, or isn't it up to the author to chose a particular syntax using different capabilities of the format.
>> >>
>> >> Also, note that Notation-3 is more than a syntax, as it includes behavior as well as representation, which is one reason Turtle was created. A purely syntactic version of Notation-3 is n3-rdf [2], which is a relatively small super-set of Turtle itself.
>> >>
>> >> Does this relate, in anyway to JSON-LD [3], which is also an RDF serialization in JSON?
>> >>
>> >> Perhaps application/rdf+json would be an appropriate mime-type.
>> >
>> > When there's a W3C standard for this, in a year or two, sure.  Using
>> > that for one of a dozen experimental candidates doesn't seem like it
>> > would help interop very much.
>> >
>> > On the other hand, I don't have a good answer for Nathan's question.
>> > What kind of media type name should one use for a random format that
>> > might be forgotten in 3 months or might take over the world (and be very
>> > widely implemented)?  I can't figure that one out.
>> >
>> >     -- Sandro
>> >
>> >> Gregg
>> >>
>> >> [1] http://www.w3.org/TeamSubmission/turtle/
>> >> [2] See N3-rdf at http://www.w3.org/DesignIssues/Notation3
>> >> [3] http://rdfa.digitalbazaar.com/specs/source/json-ld/
>> >>
>> >> On Sep 30, 2010, at 12:27 PM, Nathan wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > I'm currently working on / experimenting with two JSON based
>> >> > media-types, the first is a JSON based serialization of Notation 3, the
>> >> > other a JSON based serialization of N-Triples.
>> >> >
>> >> > I've got to the point now where I have implementations of both and need
>> >> > to content-negotiate over them, thus my initial question is what media
>> >> > type should I use in the interim whilst experimenting?
>> >> >
>> >> > For a later date, if I were to move towards seeking registration, would
>> >> > the best approach be to work on the specifications out with any
>> >> > standards body, or to do the work as an internet-draft, or?
>> >> >
>> >> > Would the recommended approach be to work towards a json-schema approach
>> >> > or towards a "+json" type?
>> >> >
>> >> > And finally, for JSON based media-types do you have any special
>> >> > considerations or gotcha's I should be taking in to account at an early
>> >> > stage?
>> >> >
>> >> > Best & TIA for any response,
>> >> >
>> >> > Nathan
>> >> > _______________________________________________
>> >> > ietf-types mailing list
>> >> > [email-masked]
>> >> > https://www.ietf.org/mailman/listinfo/ietf-types
>> >>
>> >> _______________________________________________
>> >> ietf-types mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/ietf-types
>> >>
>> >
>> >
>> > _______________________________________________
>> > ietf-types mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/ietf-types
>> >
>>
>
>
>

From: Sandro Hawke <[email-masked]>
To: mike amundsen <[email-masked]>
Organization: World Wide Web Consortium (W3C)
Date: Fri, 01 Oct 2010 00:13:49 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Q's regarding development of +json media types

On Thu, 2010-09-30 at 16:40 -0400, mike amundsen wrote:
> Experimental types should use the "prs" facet[1].
> 
> Vendor-specific types (non experimental, etc.) should use the "vnd" facet[2].
> 
> [1] http://tools.ietf.org/html/rfc4288#section-3.3
> [2] http://tools.ietf.org/html/rfc4288#section-3.2

Thanks for the pointer, and perhaps I'm being dense, but I still don't
see what subtree a developer, like Nathan, who is in the early stages of
potentially creating a standard should use.  It seems wrong to use vnd,
since he's not a vendor and (at least in this hypothetical) has no
intention of ever creating a product here, commercial or otherwise.  It
seems wrong to use prs, since that would associate the media type
forever with him, even though he might lose interest in a year, while a
community processes takes it over.

It seems like there's no name he can use when starting out that will
continue to be sensible years down the road, if the type becomes widely
adopted, perhaps being blessed by a standards body.  Is that the state
of the art, that you just have to plan to change the media type at some
point?

    -- Sandro

> mca
> http://amundsen.com/blog/
> http://twitter.com@mamund
> http://mamund.com/foaf.rdf#me
> 
> 
> #RESTFest 2010
> http://rest-fest.googlecode.com
> 
> 
> 
> 
> On Thu, Sep 30, 2010 at 16:32, Sandro Hawke <[email-masked]> wrote:
> > On Thu, 2010-09-30 at 16:23 -0400, Gregg Kellogg wrote:
> >> I don't think it makes sense to describe JSON serializations of Notation 3 or N-Triples, as these are themselves just serializations of RDF. Perhaps what you're describing is two different JSON serializations of RDF, one which is more closely related to Notation-3 and the other N-Triples. Although, note that Notation-3 is, itself, a super-set of N-Triples (as is Turtle [1]), so is there really a requirement for two different serializations, or isn't it up to the author to chose a particular syntax using different capabilities of the format.
> >>
> >> Also, note that Notation-3 is more than a syntax, as it includes behavior as well as representation, which is one reason Turtle was created. A purely syntactic version of Notation-3 is n3-rdf [2], which is a relatively small super-set of Turtle itself.
> >>
> >> Does this relate, in anyway to JSON-LD [3], which is also an RDF serialization in JSON?
> >>
> >> Perhaps application/rdf+json would be an appropriate mime-type.
> >
> > When there's a W3C standard for this, in a year or two, sure.  Using
> > that for one of a dozen experimental candidates doesn't seem like it
> > would help interop very much.
> >
> > On the other hand, I don't have a good answer for Nathan's question.
> > What kind of media type name should one use for a random format that
> > might be forgotten in 3 months or might take over the world (and be very
> > widely implemented)?  I can't figure that one out.
> >
> >     -- Sandro
> >
> >> Gregg
> >>
> >> [1] http://www.w3.org/TeamSubmission/turtle/
> >> [2] See N3-rdf at http://www.w3.org/DesignIssues/Notation3
> >> [3] http://rdfa.digitalbazaar.com/specs/source/json-ld/
> >>
> >> On Sep 30, 2010, at 12:27 PM, Nathan wrote:
> >>
> >> > Hi,
> >> >
> >> > I'm currently working on / experimenting with two JSON based
> >> > media-types, the first is a JSON based serialization of Notation 3, the
> >> > other a JSON based serialization of N-Triples.
> >> >
> >> > I've got to the point now where I have implementations of both and need
> >> > to content-negotiate over them, thus my initial question is what media
> >> > type should I use in the interim whilst experimenting?
> >> >
> >> > For a later date, if I were to move towards seeking registration, would
> >> > the best approach be to work on the specifications out with any
> >> > standards body, or to do the work as an internet-draft, or?
> >> >
> >> > Would the recommended approach be to work towards a json-schema approach
> >> > or towards a "+json" type?
> >> >
> >> > And finally, for JSON based media-types do you have any special
> >> > considerations or gotcha's I should be taking in to account at an early
> >> > stage?
> >> >
> >> > Best & TIA for any response,
> >> >
> >> > Nathan
> >> > _______________________________________________
> >> > ietf-types mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/ietf-types
> >>
> >> _______________________________________________
> >> ietf-types mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ietf-types
> >>
> >
> >
> > _______________________________________________
> > ietf-types mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf-types
> >
> 

Date: Thu, 30 Sep 2010 22:12:43 +0100
From: Nathan <[email-masked]>
Organization: webr3
To: Sandro Hawke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Q's regarding development of +json media types
Reply-To: [email-masked]

Sandro Hawke wrote:
> On Thu, 2010-09-30 at 16:23 -0400, Gregg Kellogg wrote:
>>
>> Perhaps application/rdf+json would be an appropriate mime-type.
> 
> When there's a W3C standard for this, in a year or two, sure.  Using
> that for one of a dozen experimental candidates doesn't seem like it
> would help interop very much.

Exactly, couldn't have said it better! I'd be keen to avoid 
application/(x-)(rdf+)json all together for what I'm working on.

> On the other hand, I don't have a good answer for Nathan's question.
> What kind of media type name should one use for a random format that
> might be forgotten in 3 months or might take over the world (and be very
> widely implemented)?  I can't figure that one out.

Snap, hoping somebody like Ned can give guidance :) (or anybody who has 
more of a clue than I do!)

Best,

Nathan

Date: Thu, 30 Sep 2010 22:03:42 +0100
From: Nathan <[email-masked]>
Organization: webr3
To: Gregg Kellogg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Q's regarding development of +json media types
Reply-To: [email-masked]

Hi Gregg,

Indeed one is a simple json based serialization of RDF which is very 
similar to N-Triples, and thus not specifically a serialization of 
N-Triples as you say but rather a simple JSON based serialization of RDF 
that shares many similarities with N-Triples, the same feature set if 
you will.

The N3-like JSON serialization (JSN3) started out life as 
yet-another-json-rdf serialization which was Turtle-like, however soon 
had Graph Literals added at the request of Tim Berners-Lee, who then 
swiftly followed up with another request to make it fully round-tripable 
with Notation-3 and thus to express/serialize everything Notation-3 
does. Similarly this now means that a subset of it could be used as a 
Turtle-like JSON serialization of RDF, or even an AMORD-in-RDF-like 
serialization (which is basically Turtle + Quoting) - Will cross that 
bridge later though!

With regards relating to JSON-LD, in some ways yes, as in Manu and I 
have discussed at length and gone over the design choices of both 
JSON-LD and JSN3, and also the various other JSON based serializations 
of RDF which are in the wild & feedback has been gained from many who 
work heavily with RDF, N3 and JSON - and of course much more expected 
and welcomed!

Best,

Nathan

Gregg Kellogg wrote:
> I don't think it makes sense to describe JSON serializations of Notation 3 or N-Triples, as these are themselves just serializations of RDF. Perhaps what you're describing is two different JSON serializations of RDF, one which is more closely related to Notation-3 and the other N-Triples. Although, note that Notation-3 is, itself, a super-set of N-Triples (as is Turtle [1]), so is there really a requirement for two different serializations, or isn't it up to the author to chose a particular syntax using different capabilities of the format.
> 
> Also, note that Notation-3 is more than a syntax, as it includes behavior as well as representation, which is one reason Turtle was created. A purely syntactic version of Notation-3 is n3-rdf [2], which is a relatively small super-set of Turtle itself.
> 
> Does this relate, in anyway to JSON-LD [3], which is also an RDF serialization in JSON?
> 
> Perhaps application/rdf+json would be an appropriate mime-type.
> 
> Gregg
> 
> [1] http://www.w3.org/TeamSubmission/turtle/
> [2] See N3-rdf at http://www.w3.org/DesignIssues/Notation3
> [3] http://rdfa.digitalbazaar.com/specs/source/json-ld/
> 
> On Sep 30, 2010, at 12:27 PM, Nathan wrote:
> 
>> Hi,
>>
>> I'm currently working on / experimenting with two JSON based 
>> media-types, the first is a JSON based serialization of Notation 3, the 
>> other a JSON based serialization of N-Triples.
>>
>> I've got to the point now where I have implementations of both and need 
>> to content-negotiate over them, thus my initial question is what media 
>> type should I use in the interim whilst experimenting?
>>
>> For a later date, if I were to move towards seeking registration, would 
>> the best approach be to work on the specifications out with any 
>> standards body, or to do the work as an internet-draft, or?
>>
>> Would the recommended approach be to work towards a json-schema approach 
>> or towards a "+json" type?
>>
>> And finally, for JSON based media-types do you have any special 
>> considerations or gotcha's I should be taking in to account at an early 
>> stage?
>>
>> Best & TIA for any response,
>>
>> Nathan
>> _______________________________________________
>> ietf-types mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-types
> 
> 
> 

Content-class: urn:content-classes:message
Date: Thu, 30 Sep 2010 14:03:46 -0700
From: "Krishna Sankar (ksankar)" <[email-masked]>
To: <[email-masked]>
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

Agreed and corrected.
----------------------------
6.  IANA Considerations

   This memo includes a request to IANA to register the following media
   types :

   o  application/cdmi-domain

   o  application/cdmi-capability

   o  application/cdmi-container

   o  application/cdmi-object and

   o  application/cdmi-queue

6.1.  Media Type application/cdmi-capability

   Type name: application

   Subtype name: cdmi-capability

   Required parameters: none

   Optional parameters: none

   Encoding considerations: Assumes that the representation is always
   UTF-8, as defined in [RFC3629] and any "charset" MIME parameter will
   be ignored.  The primary transport is HTTP and a base64 encoding is
   appropriate when transporting such objects over other transports like
   email.

   Security considerations: See Section 7 of draft-cdmi-mediatypes-02

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-02

   Applications that use this media type: Implementations of the Cloud
   Data Management Interface (CDMI) defined by the Storage Networking
   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold
   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.2.  Media Type application/cdmi-container

   Type name: application

   Subtype name: cdmi-container

   Required parameters: none

   Optional parameters: none

   Encoding considerations: Assumes that the representation is always
   UTF-8, as defined in [RFC3629] and any "charset" MIME parameter will
   be ignored.  The primary transport is HTTP and a base64 encoding is
   appropriate when transporting such objects over other transports like
   email.

   Security considerations: See Section 7 of draft-cdmi-mediatypes-02

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-02

   Applications that use this media type: Implementations of the Cloud
   Data Management Interface (CDMI) defined by the Storage Networking
   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold
   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.3.  Media Type application/cdmi-domain

   Type name: application

   Subtype name: cdmi-domain

   Required parameters: none

   Optional parameters: none

   Encoding considerations: Assumes that the representation is always
   UTF-8, as defined in [RFC3629] and any "charset" MIME parameter will
   be ignored.  The primary transport is HTTP and a base64 encoding is
   appropriate when transporting such objects over other transports like
   email.

   Security considerations: See Section 7 of draft-cdmi-mediatypes-02

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-02

   Applications that use this media type: Implementations of the Cloud
   Data Management Interface (CDMI) defined by the Storage Networking
   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold
   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.4.  Media Type application/cdmi-object

   Type name: application

   Subtype name: cdmi-object

   Required parameters: none

   Optional parameters: none

   Encoding considerations: Assumes that the representation is always
   UTF-8, as defined in [RFC3629] and any "charset" MIME parameter will
   be ignored.  The primary transport is HTTP and a base64 encoding is
   appropriate when transporting such objects over other transports like
   email.

   Security considerations: See Section 7 of draft-cdmi-mediatypes-02

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-02

   Applications that use this media type: Implementations of the Cloud
   Data Management Interface (CDMI) defined by the Storage Networking
   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold
   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.5.  Media Type application/cdmi-queue

   Type name: application

   Subtype name: cdmi-queue

   Required parameters: none

   Optional parameters: none

   Encoding considerations: Assumes that the representation is always
   UTF-8, as defined in [RFC3629] and any "charset" MIME parameter will
   be ignored.  The primary transport is HTTP and a base64 encoding is
   appropriate when transporting such objects over other transports like
   email.

   Security considerations: See Section 7 of draft-cdmi-mediatypes-02

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-02

   Applications that use this media type: Implementations of the Cloud
   Data Management Interface (CDMI) defined by the Storage Networking
   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold

   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

----------------------------
Cheers
<k/>

From: Keith Moore [mailto:[email-masked]] 
Sent: Sunday, September 26, 2010 6:14 PM
To: Krishna Sankar (ksankar)
Cc: [email-masked]
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

On Sep 26, 2010, at 9:03 PM, Krishna Sankar (ksankar) wrote:

Keith,
	Thanks. Good comments. Corrected.

Thanks, but I have some additional comments.  Taking just one of these as an example:

6.1.  Media Type application/cdmi-capability

  Type name: application

  Subtype name: cdmi-capability

  Required parameters: none
                        ****

  Optional parameters: none
                         ****

  Encoding considerations: The "charset" MIME parameter, if present,
  MUST be set to "UTF-8", as defined in [RFC3629].  

You've declared that there are no parameters, either required or optional, and then you immediately say that the (nonexistent) charset parameter must be set to UTF-8.

Normally application/* types don't have a charset parameter at all.  charset is a parameter that tends to be used with text/* types.  RFC 3629 even says (in section 8) "UTF-8 is suitable for use in MIME content types under the "text" top-level type."

You can define a charset parameter for your type if you want to do so.  But if the charset is always going to be UTF-8, I don't see why you should bother.  Putting a charset parameter there just invites people to set it to something other than UTF-8.

Also, if you want to insist that the representation always be in UTF-8, the best way to do that would appear to be to simply state that the representation is always UTF-8 and that any charset parameter is to be ignored.

From: Sandro Hawke <[email-masked]>
To: Gregg Kellogg <[email-masked]>
Organization: World Wide Web Consortium (W3C)
Date: Thu, 30 Sep 2010 16:32:59 -0400
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Q's regarding development of +json media types

On Thu, 2010-09-30 at 16:23 -0400, Gregg Kellogg wrote:
> I don't think it makes sense to describe JSON serializations of Notation 3 or N-Triples, as these are themselves just serializations of RDF. Perhaps what you're describing is two different JSON serializations of RDF, one which is more closely related to Notation-3 and the other N-Triples. Although, note that Notation-3 is, itself, a super-set of N-Triples (as is Turtle [1]), so is there really a requirement for two different serializations, or isn't it up to the author to chose a particular syntax using different capabilities of the format.
> 
> Also, note that Notation-3 is more than a syntax, as it includes behavior as well as representation, which is one reason Turtle was created. A purely syntactic version of Notation-3 is n3-rdf [2], which is a relatively small super-set of Turtle itself.
> 
> Does this relate, in anyway to JSON-LD [3], which is also an RDF serialization in JSON?
> 
> Perhaps application/rdf+json would be an appropriate mime-type.

When there's a W3C standard for this, in a year or two, sure.  Using
that for one of a dozen experimental candidates doesn't seem like it
would help interop very much.

On the other hand, I don't have a good answer for Nathan's question.
What kind of media type name should one use for a random format that
might be forgotten in 3 months or might take over the world (and be very
widely implemented)?  I can't figure that one out.

     -- Sandro

> Gregg
> 
> [1] http://www.w3.org/TeamSubmission/turtle/
> [2] See N3-rdf at http://www.w3.org/DesignIssues/Notation3
> [3] http://rdfa.digitalbazaar.com/specs/source/json-ld/
> 
> On Sep 30, 2010, at 12:27 PM, Nathan wrote:
> 
> > Hi,
> > 
> > I'm currently working on / experimenting with two JSON based 
> > media-types, the first is a JSON based serialization of Notation 3, the 
> > other a JSON based serialization of N-Triples.
> > 
> > I've got to the point now where I have implementations of both and need 
> > to content-negotiate over them, thus my initial question is what media 
> > type should I use in the interim whilst experimenting?
> > 
> > For a later date, if I were to move towards seeking registration, would 
> > the best approach be to work on the specifications out with any 
> > standards body, or to do the work as an internet-draft, or?
> > 
> > Would the recommended approach be to work towards a json-schema approach 
> > or towards a "+json" type?
> > 
> > And finally, for JSON based media-types do you have any special 
> > considerations or gotcha's I should be taking in to account at an early 
> > stage?
> > 
> > Best & TIA for any response,
> > 
> > Nathan
> > _______________________________________________
> > ietf-types mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf-types
> 
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types
> 

From: Gregg Kellogg <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 30 Sep 2010 16:23:33 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Q's regarding development of +json media types

I don't think it makes sense to describe JSON serializations of Notation 3 or N-Triples, as these are themselves just serializations of RDF. Perhaps what you're describing is two different JSON serializations of RDF, one which is more closely related to Notation-3 and the other N-Triples. Although, note that Notation-3 is, itself, a super-set of N-Triples (as is Turtle [1]), so is there really a requirement for two different serializations, or isn't it up to the author to chose a particular syntax using different capabilities of the format.

Also, note that Notation-3 is more than a syntax, as it includes behavior as well as representation, which is one reason Turtle was created. A purely syntactic version of Notation-3 is n3-rdf [2], which is a relatively small super-set of Turtle itself.

Does this relate, in anyway to JSON-LD [3], which is also an RDF serialization in JSON?

Perhaps application/rdf+json would be an appropriate mime-type.

Gregg

[1] http://www.w3.org/TeamSubmission/turtle/
[2] See N3-rdf at http://www.w3.org/DesignIssues/Notation3
[3] http://rdfa.digitalbazaar.com/specs/source/json-ld/

On Sep 30, 2010, at 12:27 PM, Nathan wrote:

> Hi,
> 
> I'm currently working on / experimenting with two JSON based 
> media-types, the first is a JSON based serialization of Notation 3, the 
> other a JSON based serialization of N-Triples.
> 
> I've got to the point now where I have implementations of both and need 
> to content-negotiate over them, thus my initial question is what media 
> type should I use in the interim whilst experimenting?
> 
> For a later date, if I were to move towards seeking registration, would 
> the best approach be to work on the specifications out with any 
> standards body, or to do the work as an internet-draft, or?
> 
> Would the recommended approach be to work towards a json-schema approach 
> or towards a "+json" type?
> 
> And finally, for JSON based media-types do you have any special 
> considerations or gotcha's I should be taking in to account at an early 
> stage?
> 
> Best & TIA for any response,
> 
> Nathan
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

Date: Thu, 30 Sep 2010 13:36:54 -0600
From: Kris Zyp <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-types] Q's regarding development of +json media types

On 9/30/2010 1:27 PM, Nathan wrote:
> Hi,
>
> I'm currently working on / experimenting with two JSON based
> media-types, the first is a JSON based serialization of Notation 3,
> the other a JSON based serialization of N-Triples.
>
> I've got to the point now where I have implementations of both and
> need to content-negotiate over them, thus my initial question is
> what media type should I use in the interim whilst experimenting?
>
> For a later date, if I were to move towards seeking registration,
> would the best approach be to work on the specifications out with
> any standards body, or to do the work as an internet-draft, or?
>
> Would the recommended approach be to work towards a json-schema
> approach or towards a "+json" type?

These aren't mutually exclusive. JSON Schema doesn't discourage new
+json media types (in fact I think that should be encouraged), it
simply suggests a couple ways that new media types might choose to
reference a json schema.

Anyway, glad to hear of more +json media types in the works.

- -- 
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com

Date: Thu, 30 Sep 2010 20:27:16 +0100
From: Nathan <[email-masked]>
Organization: webr3
To: [email-masked]
Subject: [ietf-types] Q's regarding development of +json media types
Reply-To: [email-masked]

Hi,

I'm currently working on / experimenting with two JSON based 
media-types, the first is a JSON based serialization of Notation 3, the 
other a JSON based serialization of N-Triples.

I've got to the point now where I have implementations of both and need 
to content-negotiate over them, thus my initial question is what media 
type should I use in the interim whilst experimenting?

For a later date, if I were to move towards seeking registration, would 
the best approach be to work on the specifications out with any 
standards body, or to do the work as an internet-draft, or?

Would the recommended approach be to work towards a json-schema approach 
or towards a "+json" type?

And finally, for JSON based media-types do you have any special 
considerations or gotcha's I should be taking in to account at an early 
stage?

Best & TIA for any response,

Nathan

Date: Mon, 27 Sep 2010 00:47:14 -0700
From: "Stephen D. Williams" <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

  On 9/26/10 1:32 PM, Bjoern Hoehrmann wrote:
> * Stephen D. Williams wrote:
>>   On 9/26/10 2:22 AM, Anne van Kesteren wrote:
>>> On Sat, 25 Sep 2010 23:14:39 +0200, Bjoern Hoehrmann<[email-masked]>  wrote:
>>>>    http://tools.ietf.org/html/draft-hoehrmann-urlencoded -- the draft de-
>>>> scribes the application/www-form-urlencoded format, a variant of the
>>>> application/x-www-form-urlencoded format first described in RFC 1866.
>> What the character encoding errors are at the end of section 5 needs to
>> be explained, at least for 2 cases.
> I believe the first encodes a pair of surrogate code points, the second
> a character beyond U+10FFFF, the first is an overlong sequence, then it
> is a truncated sequence, and finally you have an illegal starter with
> ASCII after it. They are all prohibited by the definition of UTF-8. I do
> not think that kind of technical detail would be well-placed there, but
> I could rephrase so it refers to UTF-8 directly instead of calling it
> "character encoding errors" though that's the same thing here.

In real life, say in Java, processing such data would throw an exception in the String library decoding methods.  That's fine, 
however it is not really about the www-form-urlencoded level format/parsing, but the next level down, UTF-8.  When I read that 
section, I expected to see data malformed at that syntax level: "%HA%##", etc.  You can simply say that data that is not valid UTF-8 
produces undefined results (i.e. exceptions, etc.).  That's true of the format itself.

Stephen

Date: Mon, 27 Sep 2010 16:23:10 +0900
From: =?ISO-8859-1?Q?"Martin_J._Dürst"?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Anne van Kesteren <[email-masked]>
Cc: [email-masked], Bjoern Hoehrmann <[email-masked]>
Subject: Re: [ietf-types] The application/www-form-urlencoded format

On 2010/09/27 5:40, Anne van Kesteren wrote:
> On Sun, 26 Sep 2010 22:19:40 +0200, Bjoern Hoehrmann <[email-masked]>
> wrote:
>> * Anne van Kesteren wrote:

>>> Most other such formats ignore a leading U+FEFF.
>>
>> I can't think of any format that's always UTF-8 encoded yet allows for
>> it, but anyway, treating it as part of a name is simpler than ignoring
>> it, I think people are more likely to implement that correctly than if
>> I were to require recognizing it.
>
> text/event-stream and text/cache-manifest.

Ignoring a leading U+FEFF makes sense for formats that are in most ways 
close to files. That's the case for most MIME types. But this one is 
very clearly different; it's more like a micro-level format for a single 
line of data composed of many fields, than a file format. In that case, 
ignoring a leading U+FEFF seems to make very little sense. Also, while a 
large number of servers these days can work with UTF-8 easily, I 
wouldn't know of any server infrastructure that ingnored an U+FEFF in 
this case.

Regards,    Martin.

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

Date: Mon, 27 Sep 2010 16:18:48 +0900
From: =?ISO-8859-1?Q?"Martin_J._Dürst"?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Keith Moore <[email-masked]>
Cc: [email-masked], Bjoern Hoehrmann <[email-masked]>
Subject: Re: [ietf-types] The application/www-form-urlencoded format

+1.    Regards,   Martin.

On 2010/09/27 10:16, Keith Moore wrote:
> On Sep 26, 2010, at 6:11 PM, Ian Hickson wrote:
>
>>> My interest is in having a proper reference for the format for use in
>>> other protocols, where application/x-www-form-urlencoded already works
>>> supporting application/www-form-urlencoded is indeed not very important.
>>
>> May I suggest using a different name in that case? Having two so similarly
>> named types in active use would be quite confusing.
>
> I was thinking the same thing.
>
> Keith
>
> _______________________________________________
> 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]

Date: Mon, 27 Sep 2010 16:15:32 +0900
From: =?ISO-8859-1?Q?"Martin_J._Dürst"?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

On 2010/09/27 6:02, Bjoern Hoehrmann wrote:
> * Martin J. Dürst wrote:
>> Can you give some rough information on where
>> application/www-form-urlencoded is implemented or implementation is planned?
>
> Well, that depends on what you would consider an implementation. You can
> use it in the `enctype` attribute of the form element in a HTML document
> right now (if you use "get" as the method and UTF-8 for the document)
> and it will work in most browsers, except they use "&" as separator. The
> label as such isn't used anywhere that I know of yet. I do not know of
> anyone other than me planning to support the label.

Ok. That implies that if you use another character encoding for the 
document, it will fail, which isn't helpful at all. It also means that 
you can get exactly the same, with the above preconditions, if you use 
the x- variant.

>> Also, in many cases, an identifier without x- denotes just the same as
>> the identifier with the x-. I think it would be good if the registration
>> template contained at least a small reminder and pointer to make clear
>> that it's not exactly the same as the x- variant.
>
> As I understand it, IANA does not copy the template to its web site, and
> I don't know of anyone else using the templates out of context, and the
> form does not really have a field where this could go, so I am reluctant
> to do that.

That's okay then. But the draft should be very explicit about it.

Regards,   Martin.

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

Date: Sun, 26 Sep 2010 14:25:31 +0900
From: =?ISO-8859-1?Q?"Martin_J._Dürst"?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

Hello Björn,

Can you give some rough information on where 
application/www-form-urlencoded is implemented or implementation is planned?

Also, in many cases, an identifier without x- denotes just the same as 
the identifier with the x-. I think it would be good if the registration 
template contained at least a small reminder and pointer to make clear 
that it's not exactly the same as the x- variant.

Regards,   Martin.

On 2010/09/26 6:14, Bjoern Hoehrmann wrote:
> Hi,
>
>    http://tools.ietf.org/html/draft-hoehrmann-urlencoded -- the draft de-
> scribes the application/www-form-urlencoded format, a variant of the
> application/x-www-form-urlencoded format first described in RFC 1866.
> RFC 1866 recommended that implementations also accept ";" as separator,
> which the draft permits and prefers, and RFC 1866 failed to define the
> character encoding to use, the draft addresses that by mandating UTF-8,
> which is universally recommended these days. As the ampersand will be
> handled as it would be for the RFC 1866 format, I believe the formats
> are similar enough that using the very similar name is justified. [1]
>
> The draft probably still has some rough edges in the prose but the
> format is not going to change. I believe it addresses the feedback I
> got since the first draft published four years ago; public feedback at
> http://lists.w3.org/Archives/Public/www-archive/2006Sep/thread.html#msg30
>
> The template is as follows. Looking at RFC 4288 again, it seems instead
> of "8bit" the encoding considerations should be "binary".
>
>     Type name:               application
>     Subtype name:            www-form-urlencoded
>     Required parameters:     none
>     Optional parameters:     none
>
>        Note: The media type does not have a 'charset' parameter, it
>        is incorrect specify one and to associate any significance to
>        it if specified. The character encoding is always UTF-8. The
>        Unicode encoding form signature is not supported; a leading
>        U+FEFF character will be considered part of a<name>.
>
>     Encoding considerations: 8bit
>
>     Security considerations: See section 9.
>     Interoperability considerations:
>        None, except as noted in other sections of this document.
>
>     Published specification: RFC XXXX
>     Applications that use this media type:
>        Systems that interchange data sets of name-value pairs.
>
>     Additional information:
>
>        Magic number(s):             n/a
>        File extension(s):           n/a
>        Macintosh file type code(s): TEXT
>        Fragment identifiers:        n/a
>
>     Person&  email address to contact for further information:
>        See Author's Address section.
>
>     Intended usage:          COMMON
>     Restrictions on usage:   n/a
>     Author:                  See Author's Address section.
>     Change controller:       The IESG.
>
> [1] The regular expression to match both names is slightly simpler if
>      they only differ in the "x-", and it seems fitting to standardize
>      an "x-" type by removing the "x-", but if there is a good argument
>      why using similar names is a bad idea, I am also quite open to name
>      it application/name-value-pairs or something like that instead.
>
> Let me know if anyone sees any other problem. Thanks,

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

From: Keith Moore <[email-masked]>
Date: Sun, 26 Sep 2010 21:16:29 -0400
To: Ian Hickson <[email-masked]>
Cc: [email-masked], Bjoern Hoehrmann <[email-masked]>
Subject: Re: [ietf-types] The application/www-form-urlencoded format

On Sep 26, 2010, at 6:11 PM, Ian Hickson wrote:

>> My interest is in having a proper reference for the format for use in
>> other protocols, where application/x-www-form-urlencoded already works
>> supporting application/www-form-urlencoded is indeed not very important.
> 
> May I suggest using a different name in that case? Having two so similarly 
> named types in active use would be quite confusing.

I was thinking the same thing.

Keith

From: Keith Moore <[email-masked]>
Date: Sun, 26 Sep 2010 21:14:02 -0400
To: "Krishna Sankar (ksankar)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

--Apple-Mail-53-152680727
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Sep 26, 2010, at 9:03 PM, Krishna Sankar (ksankar) wrote:

> Keith,
> 	Thanks. Good comments. Corrected.
> 

Thanks, but I have some additional comments.  Taking just one of these as an example:

> 6.1.  Media Type application/cdmi-capability
> 
>   Type name: application
> 
>   Subtype name: cdmi-capability
> 
>   Required parameters: none
                        ****
>                      
>   Optional parameters: none
                         ****
> 
>   Encoding considerations: The "charset" MIME parameter, if present,
>   MUST be set to "UTF-8", as defined in [RFC3629].  

You've declared that there are no parameters, either required or optional, and then you immediately say that the (nonexistent) charset parameter must be set to UTF-8.

Normally application/* types don't have a charset parameter at all.  charset is a parameter that tends to be used with text/* types.  RFC 3629 even says (in section 8) "UTF-8 is suitable for use in MIME content types under the "text" top-level type."

You can define a charset parameter for your type if you want to do so.  But if the charset is always going to be UTF-8, I don't see why you should bother.  Putting a charset parameter there just invites people to set it to something other than UTF-8.

Also, if you want to insist that the representation always be in UTF-8, the best way to do that would appear to be to simply state that the representation is always UTF-8 and that any charset parameter is to be ignored.

--Apple-Mail-53-152680727
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><font class="Apple-style-span" face="Courier">On Sep 26, 2010, at 9:03 PM, Krishna Sankar (ksankar) wrote:</font></div><font class="Apple-style-span" face="Courier"><br class="Apple-interchange-newline"></font><blockquote type="cite"><div><font class="Apple-style-span" face="Courier">Keith,<br></font><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="Courier">	</font></span><font class="Apple-style-span" face="Courier">Thanks. Good comments. Corrected.<br><br></font></div></blockquote><div><font class="Apple-style-span" face="Courier"><br></font></div>Thanks, but I have some additional comments. &nbsp;Taking just one of these as an example:</div><div><font class="Apple-style-span" face="Courier"><br></font><blockquote type="cite"><div><font class="Apple-style-span" face="Courier">6.1. &nbsp;Media Type application/cdmi-capability<br><br> &nbsp;&nbsp;Type name: application<br><br> &nbsp;&nbsp;Subtype name: cdmi-capability<br><br> &nbsp;&nbsp;Required parameters: none<br></font></div></blockquote><font class="Apple-style-span" face="Courier">&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;****<br></font><blockquote type="cite"><div><font class="Apple-style-span" face="Courier">&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<br> &nbsp;&nbsp;Optional parameters: none<br></font></div></blockquote><font class="Apple-style-span" face="Courier">&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ****<br></font><blockquote type="cite"><div><font class="Apple-style-span" face="Courier"><br> &nbsp;&nbsp;Encoding considerations: The "charset" MIME parameter, if present,<br> &nbsp;&nbsp;MUST be set to "UTF-8", as defined in [RFC3629]. &nbsp;</font></div></blockquote><div><br></div><div>You've declared that there are no parameters, either required or optional, and then you immediately say that the (nonexistent) charset parameter must be set to UTF-8.</div><div><br></div><div>Normally application/* types don't have a charset parameter at all. &nbsp;charset is a parameter that tends to be used with text/* types. &nbsp;RFC 3629 even says (in section 8) "<span class="Apple-style-span" style="white-space: pre-wrap; "><font class="Apple-style-span" face="Courier">UTF-8 is suitable for use in MIME </font></span><span class="Apple-style-span" style="white-space: pre-wrap; "><font class="Apple-style-span" face="Courier">content types under the "text" top-level type.</font></span><span class="Apple-style-span" style="white-space: pre-wrap; ">"</span></div><div><br></div><div>You can define a charset parameter for your type if you want to do so. &nbsp;But if the charset is always going to be UTF-8, I don't see why you should bother. &nbsp;Putting a charset parameter there just invites people to set it to something other than UTF-8.</div><div><br></div><div>Also, if you want to insist that the representation always be in UTF-8, the best way to do that would appear to be to simply state that the representation is always UTF-8 and that any charset parameter is to be ignored.</div><div><br></div><div><br></div><div><br></div></div><br></body></html>
--Apple-Mail-53-152680727--

Date: Mon, 27 Sep 2010 00:55:47 +0000 (UTC)
From: Ian Hickson <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Content-Style-Type: text/css
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

On Mon, 27 Sep 2010, Bjoern Hoehrmann wrote:
> * Ian Hickson wrote:
> >> >After having thought about it some more I am doubting this would be a very  
> >> >useful addition though. The benefit over application/x-www-form-urlencoded  
> >> >seems marginal. Not high enough to warrant the cost.
> >> 
> >> My interest is in having a proper reference for the format for use in
> >> other protocols, where application/x-www-form-urlencoded already works
> >> supporting application/www-form-urlencoded is indeed not very important.
> >
> >May I suggest using a different name in that case? Having two so similarly 
> >named types in active use would be quite confusing.
> 
> The names are as different as the formats are, if I changed the name to,
> say, application/name-value-pairs, then there would probably be someone
> saying it's confusing to have so different names even though the actual
> differences in the format are trivial if not almost meaningless in prac-
> tise. So long as I lack a convincing argument to counter that I'll stick
> with the current name.

The problem is that since they aren't compatible, yet have so similar 
names, it's quite likely that people will get the names wrong and end up 
with interoperability problems. This would be _especially_ confusing if 
any software ends up implementing both.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From: Bjoern Hoehrmann <[email-masked]>
To: Ian Hickson <[email-masked]>
Date: Mon, 27 Sep 2010 01:30:38 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

* Ian Hickson wrote:
>> >After having thought about it some more I am doubting this would be a very  
>> >useful addition though. The benefit over application/x-www-form-urlencoded  
>> >seems marginal. Not high enough to warrant the cost.
>> 
>> My interest is in having a proper reference for the format for use in
>> other protocols, where application/x-www-form-urlencoded already works
>> supporting application/www-form-urlencoded is indeed not very important.
>
>May I suggest using a different name in that case? Having two so similarly 
>named types in active use would be quite confusing.

The names are as different as the formats are, if I changed the name to,
say, application/name-value-pairs, then there would probably be someone
saying it's confusing to have so different names even though the actual
differences in the format are trivial if not almost meaningless in prac-
tise. So long as I lack a convincing argument to counter that I'll stick
with the current name.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Sun, 26 Sep 2010 22:11:01 +0000 (UTC)
From: Ian Hickson <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Content-Style-Type: text/css
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

On Sun, 26 Sep 2010, Bjoern Hoehrmann wrote:
> * Anne van Kesteren wrote:
> >I suppose. And I guess if we ever decide to implement any of this we could  
> >make more specific requirements in the forms section of HTML for that  
> >class of implementors.
> 
> That would be reasonable, although I would expect the rules for this
> type and the "x-" type to be the same except for the separator.
> 
> >After having thought about it some more I am doubting this would be a very  
> >useful addition though. The benefit over application/x-www-form-urlencoded  
> >seems marginal. Not high enough to warrant the cost.
> 
> My interest is in having a proper reference for the format for use in
> other protocols, where application/x-www-form-urlencoded already works
> supporting application/www-form-urlencoded is indeed not very important.

May I suggest using a different name in that case? Having two so similarly 
named types in active use would be quite confusing.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From: Bjoern Hoehrmann <[email-masked]>
To: "Anne van Kesteren" <[email-masked]>
Date: Sun, 26 Sep 2010 23:52:17 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

* Anne van Kesteren wrote:
>I suppose. And I guess if we ever decide to implement any of this we could  
>make more specific requirements in the forms section of HTML for that  
>class of implementors.

That would be reasonable, although I would expect the rules for this
type and the "x-" type to be the same except for the separator.

>After having thought about it some more I am doubting this would be a very  
>useful addition though. The benefit over application/x-www-form-urlencoded  
>seems marginal. Not high enough to warrant the cost.

My interest is in having a proper reference for the format for use in
other protocols, where application/x-www-form-urlencoded already works
supporting application/www-form-urlencoded is indeed not very important.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From: Bjoern Hoehrmann <[email-masked]>
To: =?ISO-8859-1?Q?"Martin_J._Dürst"?= <[email-masked]>
Date: Sun, 26 Sep 2010 23:02:51 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

* Martin J. Dürst wrote:
>Can you give some rough information on where 
>application/www-form-urlencoded is implemented or implementation is planned?

Well, that depends on what you would consider an implementation. You can
use it in the `enctype` attribute of the form element in a HTML document
right now (if you use "get" as the method and UTF-8 for the document)
and it will work in most browsers, except they use "&" as separator. The
label as such isn't used anywhere that I know of yet. I do not know of
anyone other than me planning to support the label.

>Also, in many cases, an identifier without x- denotes just the same as 
>the identifier with the x-. I think it would be good if the registration 
>template contained at least a small reminder and pointer to make clear 
>that it's not exactly the same as the x- variant.

As I understand it, IANA does not copy the template to its web site, and
I don't know of anyone else using the templates out of context, and the
form does not really have a field where this could go, so I am reluctant
to do that.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

To: "Bjoern Hoehrmann" <[email-masked]>
Date: Sun, 26 Sep 2010 22:40:37 +0200
From: "Anne van Kesteren" <[email-masked]>
Organization: Opera Software
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

On Sun, 26 Sep 2010 22:19:40 +0200, Bjoern Hoehrmann <[email-masked]>  
wrote:
> * Anne van Kesteren wrote:
>> I think it is unfortunate it still allows encoding in various ways. So
>> while things could be more readable as you pointed out in the past user
>> agents are still allowed to obscure most everything.
>
> I do think that encoder implementers can make reasonable choices about
> that. If an implementer decides it's best to escape, say, the zero-width
> space character because it's invisible then I see nothing wrong with
> that. If another implementer decides to not escape it, that's fine too.

I suppose. And I guess if we ever decide to implement any of this we could  
make more specific requirements in the forms section of HTML for that  
class of implementors.

After having thought about it some more I am doubting this would be a very  
useful addition though. The benefit over application/x-www-form-urlencoded  
seems marginal. Not high enough to warrant the cost.

>> The bug about + seems to be still be there. Escapes are first decoded  
>> and
>> then + is replaced with U+0020. Also application/x-www-form-urlencoded  
>> is
>> on its way of being standardized as part of HTML5 now.
>
> I don't think there is anything that "HTML5" could standardize about it,
> other than define how form submission using that type should be imple-
> mented in HTML implementations. As for the +, the text refers to the ab-
> stract syntax tree you get when parsing a string using the grammar, so
> an escaped plus sign is no instance of `plus`. I take it that's one of
> the text's rough edges I should smooth out.

I guess. I'm not very good at reading grammar / prose combinations. (I  
thought that after the escape was handled you would have instances of  
plus.)

>> Most other such formats ignore a leading U+FEFF.
>
> I can't think of any format that's always UTF-8 encoded yet allows for
> it, but anyway, treating it as part of a name is simpler than ignoring
> it, I think people are more likely to implement that correctly than if
> I were to require recognizing it.

text/event-stream and text/cache-manifest.

-- 
Anne van Kesteren
http://annevankesteren.nl/

From: Bjoern Hoehrmann <[email-masked]>
To: "Stephen D. Williams" <[email-masked]>
Date: Sun, 26 Sep 2010 22:32:42 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

* Stephen D. Williams wrote:
>  On 9/26/10 2:22 AM, Anne van Kesteren wrote:
>> On Sat, 25 Sep 2010 23:14:39 +0200, Bjoern Hoehrmann <[email-masked]> wrote:
>>>   http://tools.ietf.org/html/draft-hoehrmann-urlencoded -- the draft de-
>>> scribes the application/www-form-urlencoded format, a variant of the
>>> application/x-www-form-urlencoded format first described in RFC 1866.
>
>What the character encoding errors are at the end of section 5 needs to
>be explained, at least for 2 cases.

I believe the first encodes a pair of surrogate code points, the second
a character beyond U+10FFFF, the first is an overlong sequence, then it
is a truncated sequence, and finally you have an illegal starter with
ASCII after it. They are all prohibited by the definition of UTF-8. I do
not think that kind of technical detail would be well-placed there, but
I could rephrase so it refers to UTF-8 directly instead of calling it
"character encoding errors" though that's the same thing here.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From: Bjoern Hoehrmann <[email-masked]>
To: "Anne van Kesteren" <[email-masked]>
Date: Sun, 26 Sep 2010 22:19:40 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

* Anne van Kesteren wrote:
>I think it is unfortunate it still allows encoding in various ways. So  
>while things could be more readable as you pointed out in the past user  
>agents are still allowed to obscure most everything.

I do think that encoder implementers can make reasonable choices about
that. If an implementer decides it's best to escape, say, the zero-width
space character because it's invisible then I see nothing wrong with
that. If another implementer decides to not escape it, that's fine too.

>The bug about + seems to be still be there. Escapes are first decoded and  
>then + is replaced with U+0020. Also application/x-www-form-urlencoded is  
>on its way of being standardized as part of HTML5 now.

I don't think there is anything that "HTML5" could standardize about it,
other than define how form submission using that type should be imple-
mented in HTML implementations. As for the +, the text refers to the ab-
stract syntax tree you get when parsing a string using the grammar, so
an escaped plus sign is no instance of `plus`. I take it that's one of
the text's rough edges I should smooth out.

>>       Note: The media type does not have a 'charset' parameter, it
>>       is incorrect specify one and to associate any significance to
>>       it if specified. The character encoding is always UTF-8. The
>>       Unicode encoding form signature is not supported; a leading
>>       U+FEFF character will be considered part of a <name>.
>
>Most other such formats ignore a leading U+FEFF.

I can't think of any format that's always UTF-8 encoded yet allows for
it, but anyway, treating it as part of a name is simpler than ignoring
it, I think people are more likely to implement that correctly than if
I were to require recognizing it.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Sun, 26 Sep 2010 12:36:27 -0700
From: "Stephen D. Williams" <[email-masked]>
To: [email-masked]
Subject: Re: [ietf-types] The application/www-form-urlencoded format

  On 9/26/10 2:22 AM, Anne van Kesteren wrote:
> On Sat, 25 Sep 2010 23:14:39 +0200, Bjoern Hoehrmann <[email-masked]> wrote:
>>   http://tools.ietf.org/html/draft-hoehrmann-urlencoded -- the draft de-
>> scribes the application/www-form-urlencoded format, a variant of the
>> application/x-www-form-urlencoded format first described in RFC 1866.

What the character encoding errors are at the end of section 5 needs to be explained, at least for 2 cases.
>
> I think it is unfortunate it still allows encoding in various ways. So while things could be more readable as you pointed out in 
> the past user agents are still allowed to obscure most everything.

It should be the case that only what has to be encoded is encoded.  This is required for any signature canonicalization anyway.  It 
could be the case that a more restricted situation exists, although I don't see it for form submission.
> ...
>>
>> The draft probably still has some rough edges in the prose but the
>> format is not going to change. I believe it addresses the feedback I
>> got since the first draft published four years ago; public feedback at
>> http://lists.w3.org/Archives/Public/www-archive/2006Sep/thread.html#msg30
>
> The bug about + seems to be still be there. Escapes are first decoded and then + is replaced with U+0020. Also 
> application/x-www-form-urlencoded is on its way of being standardized as part of HTML5 now.

I was just debugging an Oauth implementation (customized RFC 5849) that has this kind of mistake, plus they used the older set of 
unreserved characters rather than those defined in RFC 3986:
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

Some specs allowed more:
RFC 2396: Section 2.3:
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"

Java's urlencoder seems broken as it is almost RFC 3986 but with '*' instead of '~':
http://download.oracle.com/javase/1.4.2/docs/api/java/net/URLEncoder.html
# The special characters "|.|", "|-|", "|*|", and "|_|" remain the same.
# The space character "| |" is converted into a plus sign "|+|".

For canonicalization purposes, RFC 5849 says in sction 3.6:
This method is different from the encoding scheme used by the
"application/x-www-form-urlencoded" content-type (for example, it
encodes space characters as "%20" and not using the "+" character).
It MAY be different from the percent-encoding functions provided by
web-development frameworks (e.g., encode different characters, use
lowercase hexadecimal characters).

They use uppercase hex and ' '->'%20 rather than the option of ' '->'+'.

If ' '->'+' is to be used, it has to be done after percent encoding so that '+' gets percent encoded before ' '->'+'. At this point 
however, most people can read "%20" as space almost as fast as '+'.  On the other hand, '+' is more compact and is still more 
readable.  A spec should deterministically choose one or the other so that signatures can be done without further agreement.  
Signing a form is a common need.

While these specs have different purposes, it is often the case (as with OAuth), that key/value pairs can show up in HTTP headers, 
POST bodies that may be www-form-urlencoded or something like XML, in the URL as a query string, along with being canonicalized for 
HMAC signature.  Unifying the operations reduces confusion and coding.

>
>
>>       Note: The media type does not have a 'charset' parameter, it
>>       is incorrect specify one and to associate any significance to
>>       it if specified. The character encoding is always UTF-8. The
>>       Unicode encoding form signature is not supported; a leading
>>       U+FEFF character will be considered part of a <name>.
>
> Most other such formats ignore a leading U+FEFF.

U+FEFF, the BOM, is only needed where the encoding can be something other than UTF-8.  If there is no choice, it isn't needed and 
probably shouldn't be present unless the situation might change.  If UTF-16 can be used, then it is needed.

>
>
>> [1] The regular expression to match both names is slightly simpler if
>>     they only differ in the "x-", and it seems fitting to standardize
>>     an "x-" type by removing the "x-", but if there is a good argument
>>     why using similar names is a bad idea, I am also quite open to name
>>     it application/name-value-pairs or something like that instead.
>
> Well, application/x-www-form-urlencoded is not going away anytime soon. It is what you get for <form> by default. That some 
> consider it non-standard is just semantics. Having said that I do not mind dropping the x- for an improved version of that format.
>
>

sdw

-- 
Stephen D. Williams [email-masked] [email-masked] LinkedIn: http://sdw.st/in
V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407
AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres
Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer

To: [email-masked], "Bjoern Hoehrmann" <[email-masked]>
Date: Sun, 26 Sep 2010 11:22:40 +0200
From: "Anne van Kesteren" <[email-masked]>
Organization: Opera Software
Subject: Re: [ietf-types] The application/www-form-urlencoded format

On Sat, 25 Sep 2010 23:14:39 +0200, Bjoern Hoehrmann <[email-masked]>  
wrote:
>   http://tools.ietf.org/html/draft-hoehrmann-urlencoded -- the draft de-
> scribes the application/www-form-urlencoded format, a variant of the
> application/x-www-form-urlencoded format first described in RFC 1866.

I think it is unfortunate it still allows encoding in various ways. So  
while things could be more readable as you pointed out in the past user  
agents are still allowed to obscure most everything.

> RFC 1866 recommended that implementations also accept ";" as separator,
> which the draft permits and prefers, and RFC 1866 failed to define the
> character encoding to use, the draft addresses that by mandating UTF-8,
> which is universally recommended these days. As the ampersand will be
> handled as it would be for the RFC 1866 format, I believe the formats
> are similar enough that using the very similar name is justified. [1]
>
> The draft probably still has some rough edges in the prose but the
> format is not going to change. I believe it addresses the feedback I
> got since the first draft published four years ago; public feedback at
> http://lists.w3.org/Archives/Public/www-archive/2006Sep/thread.html#msg30

The bug about + seems to be still be there. Escapes are first decoded and  
then + is replaced with U+0020. Also application/x-www-form-urlencoded is  
on its way of being standardized as part of HTML5 now.

>       Note: The media type does not have a 'charset' parameter, it
>       is incorrect specify one and to associate any significance to
>       it if specified. The character encoding is always UTF-8. The
>       Unicode encoding form signature is not supported; a leading
>       U+FEFF character will be considered part of a <name>.

Most other such formats ignore a leading U+FEFF.

> [1] The regular expression to match both names is slightly simpler if
>     they only differ in the "x-", and it seems fitting to standardize
>     an "x-" type by removing the "x-", but if there is a good argument
>     why using similar names is a bad idea, I am also quite open to name
>     it application/name-value-pairs or something like that instead.

Well, application/x-www-form-urlencoded is not going away anytime soon. It  
is what you get for <form> by default. That some consider it non-standard  
is just semantics. Having said that I do not mind dropping the x- for an  
improved version of that format.

-- 
Anne van Kesteren
http://annevankesteren.nl/

From: Bjoern Hoehrmann <[email-masked]>
To: [email-masked]
Date: Sat, 25 Sep 2010 23:14:39 +0200
Subject: [ietf-types] The application/www-form-urlencoded format

Hi,

  http://tools.ietf.org/html/draft-hoehrmann-urlencoded -- the draft de-
scribes the application/www-form-urlencoded format, a variant of the
application/x-www-form-urlencoded format first described in RFC 1866.
RFC 1866 recommended that implementations also accept ";" as separator,
which the draft permits and prefers, and RFC 1866 failed to define the
character encoding to use, the draft addresses that by mandating UTF-8,
which is universally recommended these days. As the ampersand will be
handled as it would be for the RFC 1866 format, I believe the formats
are similar enough that using the very similar name is justified. [1]

The draft probably still has some rough edges in the prose but the
format is not going to change. I believe it addresses the feedback I
got since the first draft published four years ago; public feedback at
http://lists.w3.org/Archives/Public/www-archive/2006Sep/thread.html#msg30

The template is as follows. Looking at RFC 4288 again, it seems instead
of "8bit" the encoding considerations should be "binary".

   Type name:               application
   Subtype name:            www-form-urlencoded
   Required parameters:     none
   Optional parameters:     none

      Note: The media type does not have a 'charset' parameter, it
      is incorrect specify one and to associate any significance to
      it if specified. The character encoding is always UTF-8. The
      Unicode encoding form signature is not supported; a leading
      U+FEFF character will be considered part of a <name>.

   Encoding considerations: 8bit

   Security considerations: See section 9.
   Interoperability considerations:
      None, except as noted in other sections of this document.

   Published specification: RFC XXXX
   Applications that use this media type:
      Systems that interchange data sets of name-value pairs.

   Additional information:

      Magic number(s):             n/a
      File extension(s):           n/a
      Macintosh file type code(s): TEXT
      Fragment identifiers:        n/a

   Person & email address to contact for further information:
      See Author's Address section.

   Intended usage:          COMMON
   Restrictions on usage:   n/a
   Author:                  See Author's Address section.
   Change controller:       The IESG.

[1] The regular expression to match both names is slightly simpler if
    they only differ in the "x-", and it seems fitting to standardize
    an "x-" type by removing the "x-", but if there is a good argument
    why using similar names is a bad idea, I am also quite open to name
    it application/name-value-pairs or something like that instead.

Let me know if anyone sees any other problem. Thanks,
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Wed, 22 Sep 2010 09:30:17 -0700 (PDT)
From: Ned Freed <[email-masked]>
To: Keith Moore <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/senml+json

> On Sep 22, 2010, at 12:20 PM, Ned Freed wrote:

> >
> >> Le 22 sept. 2010 à 04:34, Peter Saint-Andre a écrit :
> >
> >>>> What I think is needed here is a revision/update to RFC 4288 to establish a
> >>>> registry of allowed +suffix constructs as well as expanded guidelines for their
> >>>> use.
> >>>
> >>> That sounds like an excellent idea.
> >
> >> Could that include usage of multiple plus for hierarchical typing?
> >
> > Anything is possible, but given past resistance to hierarchical structure in
> > media types, I think it's a little unlikely we'll get consensus on such a
> > mechanism.
> >
> > My personal take is that it's a bad idea, because I think it will encourage
> > people to regard these as properties that can be attached to anything or
> > placed in any order, which isn't how things work.

> It's been so long that I've forgotten - what was the reason to not define new
> top-level types for things like XML and JSON?

Mostly because the structuring syntax is completely orthogonal to what
top-level media types tell you. It's entirely reasonable to have image, video,
or model types that use XML or JSON. Subtypes of message that use XML or JSON
aren't out of the question either.

				Ned

Sender: [email-masked]
Date: Wed, 22 Sep 2010 21:37:19 +0200
From: Mario Salzer <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type application/senml+json

2010/9/22 Keith Moore <[email-masked]>:
>
> It's been so long that I've forgotten - what was the reason to not define new top-level types for things like XML and JSON?

Laziness and hypothetical compatibility woes. Also top-level mime
types are disallowed to prescribe a format or structure. (Well, except
for multipart/, message/, text/, vnd.*/ ...)

But basically the tertiary MIME descriptor +xml came to be as mailing
list choice award among similar suggestions, and because it was
perceived as too much effort to register an xml/ type:
http://www.imc.org/ietf-xml-mime/mail-archive/mail2.html

From: Keith Moore <[email-masked]>
Date: Wed, 22 Sep 2010 12:26:14 -0400
To: Ned Freed <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type application/senml+json

On Sep 22, 2010, at 12:20 PM, Ned Freed wrote:

> 
>> Le 22 sept. 2010 à 04:34, Peter Saint-Andre a écrit :
> 
>>>> What I think is needed here is a revision/update to RFC 4288 to establish a
>>>> registry of allowed +suffix constructs as well as expanded guidelines for their
>>>> use.
>>> 
>>> That sounds like an excellent idea.
> 
>> Could that include usage of multiple plus for hierarchical typing?
> 
> Anything is possible, but given past resistance to hierarchical structure in
> media types, I think it's a little unlikely we'll get consensus on such a
> mechanism. 
> 
> My personal take is that it's a bad idea, because I think it will encourage
> people to regard these as properties that can be attached to anything or
> placed in any order, which isn't how things work.

It's been so long that I've forgotten - what was the reason to not define new top-level types for things like XML and JSON?

Keith

Date: Wed, 22 Sep 2010 09:20:06 -0700 (PDT)
From: Ned Freed <[email-masked]>
To: Paul Libbrecht <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/senml+json

> Le 22 sept. 2010 à 04:34, Peter Saint-Andre a écrit :

> >> What I think is needed here is a revision/update to RFC 4288 to establish a
> >> registry of allowed +suffix constructs as well as expanded guidelines for their
> >> use.
> >
> > That sounds like an excellent idea.

> Could that include usage of multiple plus for hierarchical typing?

Anything is possible, but given past resistance to hierarchical structure in
media types, I think it's a little unlikely we'll get consensus on such a
mechanism. 

My personal take is that it's a bad idea, because I think it will encourage
people to regard these as properties that can be attached to anything or
placed in any order, which isn't how things work.

				Ned

From: Keith Moore <[email-masked]>
Date: Wed, 22 Sep 2010 11:47:38 -0400
To: Krishna Sankar (ksankar) <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

1. You claim to be registering application/cdmi-* but the actual subtype names in the individual templates don't start with "cdmi-".  Please add them.  I think it would be bad if application/capability, application/domain, etc. were registered.

2. Re: Encoding considerations.  Normally this would be some recommendation about whether to use base64, quoted-printable, or whatever, when transporting objects of this type over MIME email.  Your type applications don't say anything about that.  Your applications supply advice about using a charset parameter, but your proposed types don't even define a charset parameter.    Parameters defined for one type (say text/plain) do not automatically exist for other types.

I'm just guessing, but perhaps you'd like to say that since objects of type application/cdmi-* consist of utf-8 text, base64 encoding is appropriate when transporting such objects over email.  

3. Security considerations.  IANA probably knows enough to supply the missing detail, but just in case they miss it :   Type registrations are intended to be standalone.  "See Section 7" begs the question "of what?"

On Sep 21, 2010, at 9:42 PM, Krishna Sankar (ksankar) wrote:

> Corrected request for registration and have submitted draft-cdmi-mediatypes-00 :
> 
> Hi all,
>   Would like to register the following media types.  Please send me any questions, suggestions, insights and so forth.
> 
> ---------------------
> 6.  IANA Considerations
> 
>   This memo includes a request to IANA to register the following media
>   types :
> 
>   o  application/cdmi-domain
> 
>   o  application/cdmi-capability
> 
>   o  application/cdmi-container
> 
>   o  application/cdmi-object and
> 
>   o  application/cdmi-queue
> 
> 6.1.  Media Type application/cdmi-capability
> 
>   Type name: application
> 
>   Subtype name: capability
> 
>   Required parameters: none
> 
>   Optional parameters: none
> 
>   Encoding considerations: The "charset" MIME parameter, if present,
>   MUST be set to "UTF-8", as defined in [RFC3629].
> 
>   Security considerations: See Section 7.
> 
>   Interoperability considerations: none
> 
>   Published specification: draft-cdmi-mediatypes-00
> 
>   Applications that use this media type: Implementations of the Cloud
>   Data Management Interface (CDMI) defined by the Storage Networking
>   Industry Association (SNIA)
> 
>   Additional information:
> 
>      Magic number(s): none
> 
>      File extension(s): none
> 
>      Macintosh file type code(s): none
> 
>   Person and email address to contact for further information: Arnold
>   Jones [email-masked]
> 
>   Intended usage: COMMON
> 
>   Restrictions on usage: none
> 
>   Author: SNIA Cloud Storage Initiative [email-masked]
> 
>   Change controller: SNIA Cloud Storage Initiative [email-masked]
> 
> 6.2.  Media Type application/cdmi-container
> 
>   Type name: application
> 
>   Subtype name: container
> 
>   Required parameters: none
> 
>   Optional parameters: none
> 
>   Encoding considerations: The "charset" MIME parameter, if present,
>   MUST be set to "UTF-8", as defined in [RFC3629].
> 
>   Security considerations: See Section 7.
> 
>   Interoperability considerations: none
> 
>   Published specification: draft-cdmi-mediatypes-00
> 
>   Applications that use this media type: Implementations of the Cloud
>   Data Management Interface (CDMI) defined by the Storage Networking
>   Industry Association (SNIA)
> 
>   Additional information:
> 
>      Magic number(s): none
> 
>      File extension(s): none
> 
>      Macintosh file type code(s): none
> 
>   Person and email address to contact for further information: Arnold
>   Jones [email-masked]
> 
>   Intended usage: COMMON
> 
>   Restrictions on usage: none
> 
>   Author: SNIA Cloud Storage Initiative [email-masked]
> 
>   Change controller: SNIA Cloud Storage Initiative [email-masked]
> 
> 6.3.  Media Type application/cdmi-domain
> 
>   Type name: application
> 
>   Subtype name: domain
> 
>   Required parameters: none
> 
>   Optional parameters: none
> 
>   Encoding considerations: The "charset" MIME parameter, if present,
>   MUST be set to "UTF-8", as defined in [RFC3629].
> 
>   Security considerations: See Section 7.
> 
>   Interoperability considerations: none
> 
>   Published specification: draft-cdmi-mediatypes-00
> 
>   Applications that use this media type: Implementations of the Cloud
>   Data Management Interface (CDMI) defined by the Storage Networking
>   Industry Association (SNIA)
> 
>   Additional information:
> 
>      Magic number(s): none
> 
>      File extension(s): none
> 
>      Macintosh file type code(s): none
> 
>   Person and email address to contact for further information: Arnold
>   Jones [email-masked]
> 
>   Intended usage: COMMON
> 
>   Restrictions on usage: none
> 
>   Author: SNIA Cloud Storage Initiative [email-masked]
> 
>   Change controller: SNIA Cloud Storage Initiative [email-masked]
> 
> 6.4.  Media Type application/cdmi-object
> 
>   Type name: application
> 
>   Subtype name: object
> 
>   Required parameters: none
> 
>   Optional parameters: none
> 
>   Encoding considerations: The "charset" MIME parameter, if present,
>   MUST be set to "UTF-8", as defined in [RFC3629].
> 
>   Security considerations: See Section 7.
> 
>   Interoperability considerations: none
> 
>   Published specification: draft-cdmi-mediatypes-00
> 
>   Applications that use this media type: Implementations of the Cloud
>   Data Management Interface (CDMI) defined by the Storage Networking
>   Industry Association (SNIA)
> 
>   Additional information:
> 
>      Magic number(s): none
> 
>      File extension(s): none
> 
>      Macintosh file type code(s): none
> 
>   Person and email address to contact for further information: Arnold
>   Jones [email-masked]
> 
>   Intended usage: COMMON
> 
>   Restrictions on usage: none
> 
>   Author: SNIA Cloud Storage Initiative [email-masked]
> 
>   Change controller: SNIA Cloud Storage Initiative [email-masked]
> 
> 6.5.  Media Type application/cdmi-queue
> 
>   Type name: application
> 
>   Subtype name: queue
> 
>   Required parameters: none
> 
>   Optional parameters: none
> 
>   Encoding considerations: The "charset" MIME parameter, if present,
>   MUST be set to "UTF-8", as defined in [RFC3629].
> 
>   Security considerations: See Section 7.
> 
>   Interoperability considerations: none
> 
>   Published specification: draft-cdmi-mediatypes-00
> 
>   Applications that use this media type: Implementations of the Cloud
>   Data Management Interface (CDMI) defined by the Storage Networking
>   Industry Association (SNIA)
> 
>   Additional information:
> 
>      Magic number(s): none
> 
>      File extension(s): none
> 
>      Macintosh file type code(s): none
> 
>   Person and email address to contact for further information: Arnold
>   Jones [email-masked]
> 
>   Intended usage: COMMON
> 
>   Restrictions on usage: none
> 
>   Author: SNIA Cloud Storage Initiative [email-masked]
> 
>   Change controller: SNIA Cloud Storage Initiative [email-masked]
> 
> ---------------------
> Cheers & thanks
> <k/>
> 
> ------------------------------------------------------------------------------
>        |            |        Krishna Sankar, Distinguished Engineer
>       :|:          :|:       http://doubleclix.wordpress.com/about/
>      :|||:        :|||:      - Cloud Computing, Social Networks
>  ..:|||||||:.....:|||||||:.. - Semantic Social Networking = DeComplexify - ..
>      Cisco  Systems Inc      - ... Contextualize-Network-Reason & then Infer
>      (Ph) 408-853-8475       [email-masked]
> -----------------------------------------------------------------------------
> "Not all those who wander are lost ..." -J.R.R.Tolkien
> -----------------------------------------------------------------------------
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> 
> 
> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:[email-masked]] 
> Sent: Tuesday, September 21, 2010 2:59 PM
> To: Krishna Sankar (ksankar)
> Cc: [email-masked]
> Subject: Re: [ietf-types] Registration Of media types application/cdmi-*
> 
> * Krishna Sankar (ksankar) wrote:
>>               Would like to register the following media types.
>> Please send me any questions, suggestions, insights and so forth.
> 
>>  Published specification: draft-cdmi-mediatypes-01
> 
> I could not find this draft. I also tried my favourite search engine
> with some of the phrases from the templates but came up empty.
> -- 
> Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types
> 

From: Paul Libbrecht <[email-masked]>
Date: Wed, 22 Sep 2010 09:36:31 +0200
To: Peter Saint-Andre <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type application/senml+json

Le 22 sept. 2010 à 04:34, Peter Saint-Andre a écrit :

>> What I think is needed here is a revision/update to RFC 4288 to establish a
>> registry of allowed +suffix constructs as well as expanded guidelines for their
>> use. 
> 
> That sounds like an excellent idea.

Could that include usage of multiple plus for hierarchical typing?
paul

Date: Tue, 21 Sep 2010 20:34:39 -0600
From: Peter Saint-Andre <[email-masked]>
To: Ned Freed <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type application/senml+json

On 9/21/10 7:15 PM, Ned Freed wrote:

> What I think is needed here is a revision/update to RFC 4288 to establish a
> registry of allowed +suffix constructs as well as expanded guidelines for their
> use. 

That sounds like an excellent idea.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Content-class: urn:content-classes:message
Date: Tue, 21 Sep 2010 18:42:29 -0700
From: "Krishna Sankar (ksankar)" <[email-masked]>
To: <[email-masked]>
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

Corrected request for registration and have submitted draft-cdmi-mediatypes-00 :

Hi all,
   Would like to register the following media types.  Please send me any questions, suggestions, insights and so forth.

---------------------
6.  IANA Considerations

   This memo includes a request to IANA to register the following media
   types :

   o  application/cdmi-domain

   o  application/cdmi-capability

   o  application/cdmi-container

   o  application/cdmi-object and

   o  application/cdmi-queue

6.1.  Media Type application/cdmi-capability

   Type name: application

   Subtype name: capability

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The "charset" MIME parameter, if present,
   MUST be set to "UTF-8", as defined in [RFC3629].

   Security considerations: See Section 7.

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-00

   Applications that use this media type: Implementations of the Cloud
   Data Management Interface (CDMI) defined by the Storage Networking
   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold
   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.2.  Media Type application/cdmi-container

   Type name: application

   Subtype name: container

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The "charset" MIME parameter, if present,
   MUST be set to "UTF-8", as defined in [RFC3629].

   Security considerations: See Section 7.

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-00

   Applications that use this media type: Implementations of the Cloud
   Data Management Interface (CDMI) defined by the Storage Networking
   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold
   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.3.  Media Type application/cdmi-domain

   Type name: application

   Subtype name: domain

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The "charset" MIME parameter, if present,
   MUST be set to "UTF-8", as defined in [RFC3629].

   Security considerations: See Section 7.

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-00

   Applications that use this media type: Implementations of the Cloud
   Data Management Interface (CDMI) defined by the Storage Networking
   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold
   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.4.  Media Type application/cdmi-object

   Type name: application

   Subtype name: object

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The "charset" MIME parameter, if present,
   MUST be set to "UTF-8", as defined in [RFC3629].

   Security considerations: See Section 7.

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-00

   Applications that use this media type: Implementations of the Cloud
   Data Management Interface (CDMI) defined by the Storage Networking
   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold
   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.5.  Media Type application/cdmi-queue

   Type name: application

   Subtype name: queue

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The "charset" MIME parameter, if present,
   MUST be set to "UTF-8", as defined in [RFC3629].

   Security considerations: See Section 7.

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-00

   Applications that use this media type: Implementations of the Cloud
   Data Management Interface (CDMI) defined by the Storage Networking
   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold
   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

---------------------
Cheers & thanks
<k/>

------------------------------------------------------------------------------
        |            |        Krishna Sankar, Distinguished Engineer
       :|:          :|:       http://doubleclix.wordpress.com/about/
      :|||:        :|||:      - Cloud Computing, Social Networks
  ..:|||||||:.....:|||||||:.. - Semantic Social Networking = DeComplexify - ..
      Cisco  Systems Inc      - ... Contextualize-Network-Reason & then Infer
      (Ph) 408-853-8475       [email-masked]
-----------------------------------------------------------------------------
 "Not all those who wander are lost ..." -J.R.R.Tolkien
-----------------------------------------------------------------------------
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-----Original Message-----
From: Bjoern Hoehrmann [mailto:[email-masked]] 
Sent: Tuesday, September 21, 2010 2:59 PM
To: Krishna Sankar (ksankar)
Cc: [email-masked]
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

* Krishna Sankar (ksankar) wrote:
>                Would like to register the following media types.
>Please send me any questions, suggestions, insights and so forth.

>   Published specification: draft-cdmi-mediatypes-01

I could not find this draft. I also tried my favourite search engine
with some of the phrases from the templates but came up empty.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Tue, 21 Sep 2010 18:15:43 -0700 (PDT)
From: Ned Freed <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/senml+json

> On 9/21/10 1:12 PM, Cullen Jennings wrote:

> >   Type name:  application
> >
> >    Subtype name:  senml+json

> I thought that the "+xml" convention was for the special class of media
> types that represent XML MIME entities (RFC 3023). Is there a similar
> class of "JSON MIME entities" that would justify "+json"? I don't see a
> definition for such a class in RFC 4627 (not that I think it's a bad idea).

The situation surrounding the use of +suffix constructs is a little unclear.
RFC 3023 set up the rules for +xml fairly well (but see my earlier comments
about possible coupling of these suffixes to parameters like charset). However,
RFC 3023 said nothing about other +suffix constructs. And people definitely
want to use the convention for other popular structuring syntaxes. And all RFC
4288 has to say is:

    More generally, "+suffix" constructs should be used with care, given the
    possibility of conflicts with future suffix definitions. 

In my role as IANA media tyypes reviewer, I have interpreted this as meaning
that the +suffix construct should only be used when "suffix" actually
identifies a well known structuring syntax. I have pushed back on other
uses (I believe there was someone who wanted to register something like
application/vnd.typename+vendorname, for instance). But beyond that I have
allowed such registrations to go through.

What I do not do, and wish I could do, is push back on registrations of types
based on, say, JSON, saying they should be using +json. I don't believe the
current rules allow me to do that.

What I think is needed here is a revision/update to RFC 4288 to establish a
registry of allowed +suffix constructs as well as expanded guidelines for their
use. I also think pretty much any well defined structuring syntax should be
allowed in the registry. (It's not like there's a shortage of them either.)

				Ned

Content-class: urn:content-classes:message
Date: Tue, 21 Sep 2010 16:20:56 -0700
From: "Krishna Sankar (ksankar)" <[email-masked]>
To: "Peter Saint-Andre" <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB59E3.9EF50135
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have submitted the draft. 

I tried couple of times, but the web site gave me the "Previous version
does not exist for this document" error ;o( and so sent it to the
[email-masked]' alias. 

Draft attached as FYI.
Cheers
<k/>
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Saint-Andre
Sent: Tuesday, September 21, 2010 3:01 PM
To: [email-masked]
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

On 9/21/10 3:59 PM, Bjoern Hoehrmann wrote:
> * Krishna Sankar (ksankar) wrote:
>>                Would like to register the following media types.
>> Please send me any questions, suggestions, insights and so forth.
> 
>>   Published specification: draft-cdmi-mediatypes-01
> 
> I could not find this draft. I also tried my favourite search engine
> with some of the phrases from the templates but came up empty.

Having advised Krishna in writing the draft, I thought he would submit
it before posting to this list, but I seem to have been mistaken. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
ietf-types mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-types

------_=_NextPart_001_01CB59E3.9EF50135
Content-Type: text/plain;
	name="draft-cdmi-mediatypes-01.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-cdmi-mediatypes-01.txt
Content-Disposition: attachment;
	filename="draft-cdmi-mediatypes-01.txt"

------_=_NextPart_001_01CB59E3.9EF50135--

From: Bjoern Hoehrmann <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 00:09:20 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type application/senml+json

* Peter Saint-Andre wrote:
>On 9/21/10 1:12 PM, Cullen Jennings wrote:
>
>>   Type name:  application
>> 
>>    Subtype name:  senml+json
>
>I thought that the "+xml" convention was for the special class of media
>types that represent XML MIME entities (RFC 3023). Is there a similar
>class of "JSON MIME entities" that would justify "+json"? I don't see a
>definition for such a class in RFC 4627 (not that I think it's a bad idea).

There are by now a number of "+type" media types (the registry has +der,
+wbxml, +fastinfoset) and I've seen "+json" a number of times in the
wild, http://www.w3.org/TR/rdf-sparql-json-res/ for instance uses it.
http://www.alvestrand.no/pipermail/ietf-types/2006-June/001755.html has
http://www.alvestrand.no/pipermail/ietf-types/2006-June/001756.html as
only comment that I could find.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Tue, 21 Sep 2010 16:01:29 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

On 9/21/10 3:59 PM, Bjoern Hoehrmann wrote:
> * Krishna Sankar (ksankar) wrote:
>>                Would like to register the following media types.
>> Please send me any questions, suggestions, insights and so forth.
> 
>>   Published specification: draft-cdmi-mediatypes-01
> 
> I could not find this draft. I also tried my favourite search engine
> with some of the phrases from the templates but came up empty.

Having advised Krishna in writing the draft, I thought he would submit
it before posting to this list, but I seem to have been mistaken. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Date: Tue, 21 Sep 2010 16:00:44 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Subject: Re: [ietf-types] Registration of media type application/senml+json

On 9/21/10 1:12 PM, Cullen Jennings wrote:

>   Type name:  application
> 
>    Subtype name:  senml+json

I thought that the "+xml" convention was for the special class of media
types that represent XML MIME entities (RFC 3023). Is there a similar
class of "JSON MIME entities" that would justify "+json"? I don't see a
definition for such a class in RFC 4627 (not that I think it's a bad idea).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

From: Bjoern Hoehrmann <[email-masked]>
To: "Krishna Sankar (ksankar)" <[email-masked]>
Date: Tue, 21 Sep 2010 23:59:16 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

* Krishna Sankar (ksankar) wrote:
>                Would like to register the following media types.
>Please send me any questions, suggestions, insights and so forth.

>   Published specification: draft-cdmi-mediatypes-01

I could not find this draft. I also tried my favourite search engine
with some of the phrases from the templates but came up empty.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From: Bjoern Hoehrmann <[email-masked]>
To: Cullen Jennings <[email-masked]>
Date: Tue, 21 Sep 2010 23:52:28 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Registration of media type application/senml+json

* Cullen Jennings wrote:
>  Type name:  application
>
>   Subtype name:  senml+json
>
>   Required parameters:  none
>
>   Optional parameters:  none
>
>   Encoding considerations:  Must be encoded as binary.  See additional
>   constraints in [RFC4627].

If I understand correctly, this type is just a specialization of the
application/json type. If so this should simply say the considerations
are the same as for application/json.

>   Interoperability considerations:  JSON allows new fields to be
>   defined and applications should be able to ignore fields they do not
>   understand to ensure forward compatibility with extensions to this
>   specification.

I think "JSON allows new fields to be defined" is misleading here.
Perhaps you mean to say: if the name of a name-value pair in an
object is not recognized, the pair should be ignored?

>   Published specification:  RFC-AAAA
>
>   Applications that use this media type:  N/A

This should be a general description of the type of application
that uses the type, for instance, Office applications, Multimedia
applications, Cartography applications, Web browsers, ...

>   Additional information:
>
>   Magic number(s):  none
>
>   File extension(s):  senml
>
>   Macintosh file type code(s):  none
>
>   Person & email address to contact for further information:  Cullen
>   Jennings <[email-masked]>
>
>   Intended usage:  COMMON
>
>   Restrictions on usage:  None
>
>   Author:  Cullen Jennings <[email-masked]>
>
>   Change controller:  Cullen Jennings <[email-masked]>

As this is a registration in the standards tree through IETF consensus,
this should say The IETF or The IESG; I forgot which is more popular.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From: Cullen Jennings <[email-masked]>
Impp: xmpp:[email-masked]
Date: Tue, 21 Sep 2010 13:12:21 -0600
To: [email-masked]
Subject: [ietf-types] Registration of media type application/senml+json

I'm considering the following media type registration in draft-jennings-senml-03 and would appreciate any feedback. Thanks, Cullen 

  Type name:  application

   Subtype name:  senml+json

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  Must be encoded as binary.  See additional
   constraints in [RFC4627].

   Security considerations:  Sensor data can contain a wide range of
   information ranging from information that is very public, such the
   outside temperature in a given city, to very private information that
   requires integrity and confidentiality protection, such as patient
   health information.  This format does not provide any security and
   instead relies on the transport protocol that carries it to provide
   security.  Given applications need to look at the overall context of
   how this media type will be used to decide if the security is
   adequate.

   Interoperability considerations:  JSON allows new fields to be
   defined and applications should be able to ignore fields they do not
   understand to ensure forward compatibility with extensions to this
   specification.

   Published specification:  RFC-AAAA

   Applications that use this media type:  N/A

   Additional information:

   Magic number(s):  none

   File extension(s):  senml

   Macintosh file type code(s):  none

   Person & email address to contact for further information:  Cullen
   Jennings <[email-masked]>

   Intended usage:  COMMON

   Restrictions on usage:  None

   Author:  Cullen Jennings <[email-masked]>

   Change controller:  Cullen Jennings <[email-masked]>

Content-class: urn:content-classes:message
Date: Tue, 21 Sep 2010 11:49:17 -0700
From: "Krishna Sankar (ksankar)" <[email-masked]>
To: <[email-masked]>
Subject: [ietf-types] Registration Of media types application/cdmi-*

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB59BD.BDD20019
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

                Would like to register the following media types.
Please send me any questions, suggestions, insights and so forth.

---------------------

6.  IANA Considerations

   This memo includes a request to IANA to register the following media

   types :

   o  application/cdmi-domain

   o  application/cdmi-capability

   o  application/cdmi-container

   o  application/cdmi-object and

   o  application/cdmi-queue

6.1.  Media Type application/cdmi-capability

   Type name: application

   Subtype name: capability

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The "charset" MIME parameter, if present,

   MUST be set to "UTF-8", as defined in [RFC3629].

   Security considerations: See Section 7.

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-01

   Applications that use this media type: Implementations of the Cloud

   Data Management Interface (CDMI) defined by the Storage Networking

   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold

   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.2.  Media Type application/cdmi-container

   Type name: application

   Subtype name: container

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The "charset" MIME parameter, if present,

   MUST be set to "UTF-8", as defined in [RFC3629].

   Security considerations: See Section 7.

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-01

   Applications that use this media type: Implementations of the Cloud

   Data Management Interface (CDMI) defined by the Storage Networking

   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold

   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.3.  Media Type application/cdmi-domain

   Type name: application

   Subtype name: domain

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The "charset" MIME parameter, if present,

   MUST be set to "UTF-8", as defined in [RFC3629].

   Security considerations: See Section 7.

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-01

   Applications that use this media type: Implementations of the Cloud

   Data Management Interface (CDMI) defined by the Storage Networking

   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold

   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.4.  Media Type application/cdmi-object

   Type name: application

   Subtype name: object

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The "charset" MIME parameter, if present,

   MUST be set to "UTF-8", as defined in [RFC3629].

   Security considerations: See Section 7.

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-01

   Applications that use this media type: Implementations of the Cloud

   Data Management Interface (CDMI) defined by the Storage Networking

   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold

   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

6.5.  Media Type application/cdmi-queue

   Type name: application

   Subtype name: queue

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The "charset" MIME parameter, if present,

   MUST be set to "UTF-8", as defined in [RFC3629].

   Security considerations: See Section 7.

   Interoperability considerations: none

   Published specification: draft-cdmi-mediatypes-01

   Applications that use this media type: Implementations of the Cloud

   Data Management Interface (CDMI) defined by the Storage Networking

   Industry Association (SNIA)

   Additional information:

      Magic number(s): none

      File extension(s): none

      Macintosh file type code(s): none

   Person and email address to contact for further information: Arnold

   Jones [email-masked]

   Intended usage: COMMON

   Restrictions on usage: none

   Author: SNIA Cloud Storage Initiative [email-masked]

   Change controller: SNIA Cloud Storage Initiative [email-masked]

---------------------

Cheers & thanks

<k/>

------------------------------------------------------------------------
------

        |            |        Krishna Sankar, Distinguished Engineer

       :|:          :|:       http://doubleclix.wordpress.com/about/

      :|||:        :|||:      - Cloud Computing, Social Networks

  ..:|||||||:.....:|||||||:.. - Semantic Social Networking =
DeComplexify - ..

      Cisco  Systems Inc      - ... Contextualize-Network-Reason & then
Infer

      (Ph) 408-853-8475       [email-masked]

------------------------------------------------------------------------
-----

 "Not all those who wander are lost ..." -J.R.R.Tolkien

------------------------------------------------------------------------
-----

For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

 

------_=_NextPart_001_01CB59BD.BDD20019
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=WordSection1>

<p class=MsoNormal>Hi all,<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Would
like to register the following media types. &nbsp;Please send me any questions,
suggestions, insights and so forth.<o:p></o:p></p>

<p class=MsoNormal>---------------------<o:p></o:p></p>

<p class=MsoNormal>6.&nbsp; IANA Considerations<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; This memo includes a request to IANA to
register the following media<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; types :<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; o&nbsp; application/cdmi-domain<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; o&nbsp; application/cdmi-capability<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; o&nbsp; application/cdmi-container<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; o&nbsp; application/cdmi-object and<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; o&nbsp; application/cdmi-queue<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>6.1.&nbsp; Media Type application/cdmi-capability<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Type name: application<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Subtype name: capability<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Required parameters: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Optional parameters: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Encoding considerations: The
&quot;charset&quot; MIME parameter, if present,<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; MUST be set to &quot;UTF-8&quot;, as defined in
[RFC3629].<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Security considerations: See Section 7.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Interoperability considerations: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Published specification:
draft-cdmi-mediatypes-01<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Applications that use this media type:
Implementations of the Cloud<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Data Management Interface (CDMI) defined by the
Storage Networking<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Industry Association (SNIA)<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Additional information:<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Magic number(s): none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; File extension(s): none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Macintosh file type code(s):
none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Person and email address to contact for further
information: Arnold<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Jones [email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Intended usage: COMMON<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Restrictions on usage: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Author: SNIA Cloud Storage Initiative
[email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Change controller: SNIA Cloud Storage
Initiative [email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>6.2.&nbsp; Media Type application/cdmi-container<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Type name: application<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Subtype name: container<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Required parameters: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Optional parameters: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Encoding considerations: The
&quot;charset&quot; MIME parameter, if present,<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; MUST be set to &quot;UTF-8&quot;, as defined in
[RFC3629].<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Security considerations: See Section 7.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Interoperability considerations: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Published specification: draft-cdmi-mediatypes-01<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Applications that use this media type:
Implementations of the Cloud<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Data Management Interface (CDMI) defined by the
Storage Networking<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Industry Association (SNIA)<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Additional information:<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Magic number(s): none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; File extension(s): none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Macintosh file type code(s):
none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Person and email address to contact for further
information: Arnold<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Jones [email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Intended usage: COMMON<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Restrictions on usage: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Author: SNIA Cloud Storage Initiative
[email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Change controller: SNIA Cloud Storage
Initiative [email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>6.3.&nbsp; Media Type application/cdmi-domain<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Type name: application<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Subtype name: domain<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Required parameters: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Optional parameters: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Encoding considerations: The
&quot;charset&quot; MIME parameter, if present,<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; MUST be set to &quot;UTF-8&quot;, as defined in
[RFC3629].<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Security considerations: See Section 7.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Interoperability considerations: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Published specification:
draft-cdmi-mediatypes-01<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Applications that use this media type:
Implementations of the Cloud<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Data Management Interface (CDMI) defined by the
Storage Networking<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Industry Association (SNIA)<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Additional information:<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Magic number(s): none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; File extension(s): none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Macintosh file type code(s):
none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Person and email address to contact for further
information: Arnold<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Jones [email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Intended usage: COMMON<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Restrictions on usage: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Author: SNIA Cloud Storage Initiative
[email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Change controller: SNIA Cloud Storage
Initiative [email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>6.4.&nbsp; Media Type application/cdmi-object<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Type name: application<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Subtype name: object<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Required parameters: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Optional parameters: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Encoding considerations: The
&quot;charset&quot; MIME parameter, if present,<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; MUST be set to &quot;UTF-8&quot;, as defined in
[RFC3629].<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Security considerations: See Section 7.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Interoperability considerations: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Published specification:
draft-cdmi-mediatypes-01<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Applications that use this media type:
Implementations of the Cloud<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Data Management Interface (CDMI) defined by the
Storage Networking<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Industry Association (SNIA)<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Additional information:<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Magic number(s): none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; File extension(s): none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Macintosh file type code(s):
none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Person and email address to contact for further
information: Arnold<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Jones [email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Intended usage: COMMON<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Restrictions on usage: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Author: SNIA Cloud Storage Initiative
[email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Change controller: SNIA Cloud Storage
Initiative [email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>6.5.&nbsp; Media Type application/cdmi-queue<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Type name: application<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Subtype name: queue<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Required parameters: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Optional parameters: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Encoding considerations: The
&quot;charset&quot; MIME parameter, if present,<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; MUST be set to &quot;UTF-8&quot;, as defined in
[RFC3629].<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Security considerations: See Section 7.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Interoperability considerations: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Published specification:
draft-cdmi-mediatypes-01<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Applications that use this media type:
Implementations of the Cloud<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Data Management Interface (CDMI) defined by the
Storage Networking<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Industry Association (SNIA)<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Additional information:<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Magic number(s): none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; File extension(s): none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Macintosh file type code(s):
none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Person and email address to contact for further
information: Arnold<o:p></o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Jones [email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Intended usage: COMMON<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Restrictions on usage: none<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Author: SNIA Cloud Storage Initiative
[email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>&nbsp;&nbsp; Change controller: SNIA Cloud Storage
Initiative [email-masked]<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>---------------------<o:p></o:p></p>

<p class=MsoNormal>Cheers &amp; thanks<o:p></o:p></p>

<p class=MsoNormal>&lt;k/&gt;<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>------------------------------------------------------------------------------<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Krishna Sankar, Distinguished
Engineer<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:|:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:|:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://doubleclix.wordpress.com/about/<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:|||:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:|||:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Cloud Computing, Social Networks<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>&nbsp;
..:|||||||:.....:|||||||:.. - Semantic Social Networking = DeComplexify - ..<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Cisco&nbsp; Systems Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - ...
Contextualize-Network-Reason &amp; then Infer<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(Ph) 408-853-8475&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a
href="mailto:[email-masked]">[email-masked]</a><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>-----------------------------------------------------------------------------<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>&nbsp;&quot;Not
all those who wander are lost ...&quot; -J.R.R.Tolkien<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>-----------------------------------------------------------------------------<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'>For
corporate legal information go to:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.5pt;font-family:Consolas'><a
href="http://www.cisco.com/web/about/doing_business/legal/cri/index.html">http://www.cisco.com/web/about/doing_business/legal/cri/index.html</a><o:p></o:p></span></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01CB59BD.BDD20019--

Date: Sun, 19 Sep 2010 08:44:06 -0700 (PDT)
From: Ned Freed <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Subject: Re: [ietf-types] Review of application/ccmp+xml

> * Ned Freed wrote:
> >I'm sorry, but I believe a much bigger potential security vulnerability is
> >introduced by the potential of there being a silly state difference between the
> >character encoding listed in the XML proper and what's in the charset
> >parameter.

> The problem can be avoided by avoiding the +xml convention. For +xml
> types the problem exists whether or not the registration includes a
> charset parameter.

On the contrary, you cannot assume +xml will be recogized and confer special
processing onto an otherwise unknown type. And a type may be recognized by name
and processed as XML, along with its charset parameter, even without +xml being
part of the name. So at most the +xml MAY result in a silly state causing a
problem; the absence of +xml in no way can be assumed to prevent such problems
from occurring.

I should also point out that I see nothing in RFC 3023 that says the presence
of +xml means a charset parameter is meaningful on a given subtype. The only
mechanism in MIME that can associate a parameter with an entire group of
subtypes is the primary type, e.g., a charset parameter on a text type always
has the same meaning. We're talking about application types here, which don't
have such semantics.

				Ned

From: Bjoern Hoehrmann <[email-masked]>
To: Ned Freed <[email-masked]>
Date: Sun, 19 Sep 2010 03:46:27 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/ccmp+xml

* Ned Freed wrote:
>I'm sorry, but I believe a much bigger potential security vulnerability is
>introduced by the potential of there being a silly state difference between the
>character encoding listed in the XML proper and what's in the charset
>parameter.

The problem can be avoided by avoiding the +xml convention. For +xml
types the problem exists whether or not the registration includes a
charset parameter.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Sat, 18 Sep 2010 18:18:37 -0700 (PDT)
From: Ned Freed <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Subject: Re: [ietf-types] Review of application/ccmp+xml

> * Ned Freed wrote:
> >>    Optional parameters:  charset
> >>       Indicates the character encoding of enclosed XML for which the
> >>       default is UTF-8.
> >>    Encoding considerations:  Uses XML, which can employ 8-bit
> >>       characters, depending on the character encoding used.  See RFC
> >>       3023 [RFC3023], section 3.2.
> >
> >What you have here is OK, but I note that all of the examples in the draft use
> >utf-8 and have the charset embedded in the content. If utf-8 is all that's ever
> >used, perhaps it would be better just to state that and get rid of all the
> >variability here.

> The charset parameter (and defining it exactly as it is defined for the
> application/xml media type) is necessary if you want implementations of
> only this type agree with general purpose software on what the encoding
> is. Disagreement about what the character encoding is is a typical se-
> curity vulnerability.
                                                                               
I'm sorry, but I believe a much bigger potential security vulnerability is
introduced by the potential of there being a silly state difference between the
character encoding listed in the XML proper and what's in the charset
parameter.

In other words, I believe the suggestions given in RFC 3023 are seriously off
the mark.

But the way to migitate all of this is to Just Use UTF-8. Which is why I wrote
what I wrote - there is no need for a parameter if only one charset is allowed.

				Ned

From: Bjoern Hoehrmann <[email-masked]>
To: Ned Freed <[email-masked]>
Date: Sun, 19 Sep 2010 00:30:15 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/ccmp+xml

* Ned Freed wrote:
>>    Optional parameters:  charset
>>       Indicates the character encoding of enclosed XML for which the
>>       default is UTF-8.
>>    Encoding considerations:  Uses XML, which can employ 8-bit
>>       characters, depending on the character encoding used.  See RFC
>>       3023 [RFC3023], section 3.2.
>
>What you have here is OK, but I note that all of the examples in the draft use
>utf-8 and have the charset embedded in the content. If utf-8 is all that's ever
>used, perhaps it would be better just to state that and get rid of all the
>variability here.

The charset parameter (and defining it exactly as it is defined for the
application/xml media type) is necessary if you want implementations of
only this type agree with general purpose software on what the encoding
is. Disagreement about what the character encoding is is a typical se-
curity vulnerability.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From: Bjoern Hoehrmann <[email-masked]>
To: Alan Johnston <[email-masked]>
Date: Sun, 19 Sep 2010 00:24:01 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/ccmp+xml

* Alan Johnston wrote:
>   To:  [email-masked]

(There is no need to include that.)

>   Subject:  Registration of MIME media type application/ccmp+xml
>   MIME media type name:  application
>   MIME subtype name:  ccmp+xml

This is based on an outdated template; the latest version can be found
in RFC 4288, it uses a couple of different field names and organizes
them slightly differently.

>   Required parameters:  (none)
>   Optional parameters:  charset
>      Indicates the character encoding of enclosed XML for which the
>      default is UTF-8.

(That is the overall default if no other encoding information can be
found; it is not, however, the default value of the charset parameter).

>   Encoding considerations:  Uses XML, which can employ 8-bit
>      characters, depending on the character encoding used.  See RFC
>      3023 [RFC3023], section 3.2.

RFC 3023 (section 7.1) recommends particular language to use here.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Date: Sat, 18 Sep 2010 14:54:59 -0700 (PDT)
From: Ned Freed <[email-masked]>
To: Alan Johnston <[email-masked]>
Subject: Re: [ietf-types] Review of application/ccmp+xml

> Hi,

> I would like to request a review of the application/ccmp+xml MIME type,
> registered in Section 12.3 of draft-ietf-xcon-ccmp-07:

>      http://tools.ietf.org/html/draft-ietf-xcon-ccmp-10

> The document has completed WGLC in the XCON Working Group.

> Thanks,
> Alan Johnston
> co-chair XCON WG

> - - - -

> 12.3. MIME Media Type Registration for 'application/ccmp+xml'

>    This section registers the "application/ccmp+xml" MIME type.

>    To:  [email-masked]
>    Subject:  Registration of MIME media type application/ccmp+xml
>    MIME media type name:  application
>    MIME subtype name:  ccmp+xml
>    Required parameters:  (none)
>    Optional parameters:  charset
>       Indicates the character encoding of enclosed XML for which the
>       default is UTF-8.
>    Encoding considerations:  Uses XML, which can employ 8-bit
>       characters, depending on the character encoding used.  See RFC
>       3023 [RFC3023], section 3.2.

What you have here is OK, but I note that all of the examples in the draft use
utf-8 and have the charset embedded in the content. If utf-8 is all that's ever
used, perhaps it would be better just to state that and get rid of all the
variability here.

>    Security considerations:  This content type is designed to carry
>       protocol data related conference control.  Some of the data could
>       be considered private and thus should be protected.

You also need to state whether or not the media type contains executable
content, and if it does explain how to handle it safely. (I suspect the
answer is no, but it still needs to be explicit.) 

See below for one more omission that needs correction.

You say "should be protected". THe implicaion is the media type itself doesn't
provide this capability. If that's indeed the case, it would be better to state
this in so many words. It would also be helpful to say whether or not integrity
protection is needed, and if it is, how best to provide it.

>    Interoperability considerations:  None.
>    Published specification:  RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
>       replace XXXX with the RFC number for this specification.]]
>    Applications which use this media type:  Centralized Conferencing
>       control clients and servers.
>    Additional Information:  Magic Number(s): (none)
>       File extension(s): .xml
>       Macintosh File Type Code(s): (none)
>    Person & email address to contact for further information:  Mary
>       Barnes <[email-masked]>
>    Intended usage:  LIMITED USE
>    Author/Change controller:  The IETF
>    Other information:  This media type is a specialization of
>       application/xml [RFC3023], and many of the considerations
>       described there also apply to application/ccmp+xml.

THis is too vague in such a general context to be useful. OTOH, this is
an important security consideration, so I suggest moving this to the sec
cons section where it will be specifically about security. A reference to
RFC 3023 section 10 would also help.

				Ned
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

Date: Thu, 16 Sep 2010 14:03:53 -0500
From: Alan Johnston <[email-masked]>
To: [email-masked]
Subject: [ietf-types] Review of application/ccmp+xml

Hi,

I would like to request a review of the application/ccmp+xml MIME type,
registered in Section 12.3 of draft-ietf-xcon-ccmp-07:

     http://tools.ietf.org/html/draft-ietf-xcon-ccmp-10

The document has completed WGLC in the XCON Working Group.

Thanks,
Alan Johnston
co-chair XCON WG

- - - -

12.3. MIME Media Type Registration for 'application/ccmp+xml'

   This section registers the "application/ccmp+xml" MIME type.

   To:  [email-masked]
   Subject:  Registration of MIME media type application/ccmp+xml
   MIME media type name:  application
   MIME subtype name:  ccmp+xml
   Required parameters:  (none)
   Optional parameters:  charset
      Indicates the character encoding of enclosed XML for which the
      default is UTF-8.
   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See RFC
      3023 [RFC3023], section 3.2.
   Security considerations:  This content type is designed to carry
      protocol data related conference control.  Some of the data could
      be considered private and thus should be protected.
   Interoperability considerations:  None.
   Published specification:  RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
      replace XXXX with the RFC number for this specification.]]
   Applications which use this media type:  Centralized Conferencing
      control clients and servers.
   Additional Information:  Magic Number(s): (none)
      File extension(s): .xml
      Macintosh File Type Code(s): (none)
   Person & email address to contact for further information:  Mary
      Barnes <[email-masked]>
   Intended usage:  LIMITED USE
   Author/Change controller:  The IETF
   Other information:  This media type is a specialization of
      application/xml [RFC3023], and many of the considerations
      described there also apply to application/ccmp+xml.