OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: IANA MIME Type change process


Don’t recall if this was already looked into/documented…  I checked RFC 4288 (http://www.ietf.org/rfc/rfc4288.txt) which discusses media type registrations.  Section 9 talks about the change process (attached below).

 

It appears that we can make a change if we consider it to be a “serious” error, so we’d need to provide that justification.

 

Note that it also appears that the “owner” for this MIME type is the SSTC as opposed to a specific individual.  So as long as the change request is submitted by someone in the SSTC, we should be okay (i.e. we don’t have to recruit Jeff H to submit the change).  I base this on information I found at the following links:

List of all media types: http://www.iana.org/assignments/media-types/application/

Our submission for samlmetadata: http://www.iana.org/assignments/media-types/application/samlmetadata+xml

The “contact” link for the submission: http://www.iana.org/assignments/contact-people.html#OASIS%20Security%20Services%20Technical%20Committee%20%28SSTC%29

 

So to make the change request, it looks like we simply need to use the normal submission process via: http://www.iana.org/cgi-bin/mediatypes.pl

 

 

 

9.  Change Procedures

 

   Once a media type has been published by the IANA, the owner may

   request a change to its definition.  The descriptions of the

   different registration trees above designate the "owners" of each

   type of registration.  The same procedure that would be appropriate

   for the original registration request is used to process a change

   request.

 

   Changes should be requested only when there are serious omissions or

   errors in the published specification.  When review is required, a

   change request may be denied if it renders entities that were valid

   under the previous definition invalid under the new definition.

 

   The owner of a media type may pass responsibility to another person

   or agency by informing the IANA and the ietf-types list; this can be

   done without discussion or review.

 

   The IESG may reassign responsibility for a media type.  The most

   common case of this will be to enable changes to be made to types

   where the author of the registration has died, moved out of contact

   or is otherwise unable to make changes that are important to the

   community.

 

   Media type registrations may not be deleted; media types that are no

   longer believed appropriate for use can be declared OBSOLETE by a

   change to their "intended use" field; such media types will be

   clearly marked in the lists published by the IANA.

 

 

 

 

 

 

 

 

Rob Philpott

RSA, the Security Division of EMC
Senior Technologist | e-Mail: robert.philpott@rsa.com | Office: (781) 515-7115 | Mobile: (617) 510-0893

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]