let me begin by mentioning that I am new to the IETF and the registration process and so I am soliciting the group for not only feedback for the proposed addition of "application/ddms+xml" MIME type but also the application process.
It is up to the IESG to determine whether or not this meets the criteria for registration in the standards tree. Below are my comments on the registration itself - I wrote this up as media types reviewer back when you submitted this as a vendor type.
the below application provides general background and pertinent information. If there's a need for further information, please let me know; your input is greatly appreciated.
My details comments appear below. Ned
Name : Pouya Safa
Email : psafa@fgm.com
MIME media type name : Application
MIME subtype name : (Standards Tree) ddms+xml
Required parameters : identifier, title, creator, subjectCoverage, security
First, I have to wonder if you really intend for these to be media type parameters. It is rare for a type to have this many required and optional parameters and these look more like XML elements than parameters. Second, if you really do intend to have these as parameters they must be fully defined. Please give a description of each that includes both their syntax as well as their semantics. Third, parameter names are case insensitive. So while writing "subjectCoverage" is technically OK, it is customary to write "subjectcoverage" instead.
Optional parameters :
subtitle, description, language, dates, rights, source, type,publisher, contributor, pointOfContact, format, virtualCoverage, temporalCoverage, geospatialCoverage
Same issues as required parameters.
Encoding considerations : 7bit
Security considerations : the DDMS utilizes the xs:any tag which may potentially be a security liability.
This is useful information but insufficient. All media type registrations must describe their security considerations; simply saying there are none or leaving the section blank is unacceptable. In discussing the security considerations for a media type it is necessary to cover at least these points: (1) State whether or not the media type contains active or executable content. If the media type does contain executable content explain what measures have been taken to insure that it can be executed safely, e.g. a sandbox, safe operation set, signed content, etc. (2) State whether or not the information contained in the media type needs privacy or integrity services. (3) If the answer to (2) is yes, elaborate on any privacy or integrity services the media type itself provides. One of the differences between a vendor and standards tree registration is that these issues must be covered in the standards tree. Although it is discouraged, a vendor tree registration may say "security issues have not been assessed".
Interoperability considerations :
Published specification :
The United States DoD Discovery Metadata Specification (DDMS) defines discovery metadata elements for resources posted to community and organizational shared spaces. "Discovery" is the ability to locate data assets through a consistent and flexible search. Visibility, accessibility, and understandability are the high priority goals of the DoD Net-Centric Data Strategy and publicizing DDMS promotes reusability of existing DoD XML based data.
Applications which use this media :
Any DoD or Intelligence Community XML based application utilizing data interchange and reusability.
Additional information :
1. Magic number(s) : none
2. File extension(s) : xml
3. Macintosh file type code : none
4. Object Identifiers: none
DDMS specification: https://metadata.dod.mil/mdr/irs/DDMS/index.html <https://metadata.dod.mil/mdr/irs/DDMS/index.html>
Person to contact for further information :
1. Name : Pouya Safa
2. Email : psafa@fgm.com
Intended usage : Common
Intended for data interoperability and reuse for the United States DoD and IC applications.
Author/Change controller : DoD Data Services Office
____________________________________________ Pouya Safa | FGM Inc. | Direct: 703.885.1403