Subject: Re: [ietf-types] Registration of media type application/senml+json
From: Cullen Jennings <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Date: Sun, 24 Oct 2010 16:50:18 -0600
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

Thank you very much for the helpful comments. All your points should be fixed in the next revision. 

DIff of the draft from old version is at 
http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-jennings-senml.diff.html

On Sep 21, 2010, at 3:52 PM, Bjoern Hoehrmann wrote:

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

fixed

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

yep - that's what I was trying to get at - fixed - thanks 

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

fixed 

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

fixed

> -- 
> 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: Sigfrid Lundberg <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 20 Oct 2010 12:13:58 +0200
Accept-Language: da-DK
acceptlanguage: da-DK
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [ietf-types] draft-lundberg-app-tei-xml

According to what I've learned, the mime type described in the doucment

http://datatracker.ietf.org/doc/draft-lundberg-app-tei-xml/

requires  2 weeks review by subscribers to this list. This is the registration:

Registration of MIME type 'application/tei+xml'

      MIME media type name: application

      MIME subtype name: tei+xml

      Required parameters: None

      Optional parameters: charset

         the parameter has identical semantics to the charset parameter
         of the "application/xml" media type as specified in RFC 3023
         [RFC3023].

      Encoding considerations:

         Identical to those for 'application/xml'.  See RFC 3023
         [RFC3023], Section 3.2.

      Security considerations:

         See Security considerations (Section 4) in this specification.

      Interoperability considerations:

         TEI documents are often given the extension '.xml', which is
         not uncommon for other XML document formats.

      Published specification:

         This media type registration is for TEI documents[TEI] as
         described in this document.

      Applications which use this media type:

         There are currently no known applications using the media type
         'application/tei+xml'.

      Additional information:

         Magic number(s):

            There is no single initial octet sequence that is always
            present in TEI documents.

         file extension(s):

            Common extensions are '.tei', '.teiCorpus' and '.odd'.  See
            Recognizing TEI files (Section 2) in this specification.

         Macintosh File Type Code(s)

            TEXT

         Object Identifier(s) or OID(s)

            Not applicable

Content-class: urn:content-classes:message
Date: Tue, 12 Oct 2010 08:52:41 -0700
From: "Krishna Sankar (ksankar)" <[email-masked]>
To: <[email-masked]>
Subject: Re: [ietf-types] Registration Of media types application/cdmi-*

Folks,
	Is the request ready to for IETF consideration for registration or is there anything pending from our side ? AFAIK, there is nothing to do from my end.
Cheers
<k/> 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Krishna Sankar (ksankar)
Sent: Thursday, September 30, 2010 2:04 PM
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.

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