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


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

Subject: Re: [dita] Proposal for IANA registration of Media Type for DITA ("application/dita+xml")

Thank you for the thorough research and roll-up of recommendations, Robin. I have added the work item to the DITA 1.3 proposals list as item 13100 (http://wiki.oasis-open.org/dita/DITA_1.3_Proposals) so that the DITA TC can formally approach your recommendations. I look forward to seeing how the formalization of this media type for related DITA resources (map, topic, ditaval, etc) may facilitate more direct use of the DITA standard in Web applications.
DITA and XML Consultant, Learning by Wrote
Co-Chair, OASIS DITA Technical Committee
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot

On 10/23/2011 10:26 AM, Robin Cover wrote:
DITA TC members,

Following a communication from Don Day on 2011-07-29,
I was alerted to the topic of the DITA TC's request for
IANA registration of an "'application/dita+xml' Media Type",
per the draft approved in June 2008 [1] and discussed
briefly by the TC in 2010-10 [2].

As a member of the OAIS TC Administration team, I am
currently tasked with management of IANA registrations for
ports, media/mime types, etc.  So we have opened a support
ticket to track the handling of this request from the TC,
and I have made an initial review of the TC's 2008 draft,
along with review of current rules and practices within
IANA/IESG/IETF.  We will plan to track the matter here:

My analysis suggests that the content of the TC proposal needs
to be updated to match the Registration Template now being
used the "Preliminary Community Review" phase.  The required
template [4] differs in some ways from the TC's 2008 draft [1].

Similarly, information in the templated content needs update
in several fields, including URI for the "Published
specification:" [5], the "Person & email address to contact
for further information:", etc.

When the information required by the current template is
updated and complete, it can be incorporated into the DITA
specification (any draft) or published as an independent IETF
Internet Draft.  In either case, the proposal can then be
presented to IESG for after review on the mailing list for
review: ietf-types@iana.org [3].  Per comment in [5] below,
I think it will be best to publish an I-D, but that
decision will be left to the DITA TC members.

I (as a Staff member of record) will assist the TC in
communicating the proposal + amendments to IETF/IESG, which
initially involves Preliminary Community Review, per the
current IETF RFC governing proposals:

  "Preliminary Community Review

   Notice of a potential media type registration in the
   standards tree MUST be sent to the "ietf-types@iana.org"
   mailing list for review. This mailing list has been
   established for the purpose of reviewing proposed media
   and access types...

   The intent of the public posting to this list is to
   solicit comments and feedback on the choice of
   type/subtype name, the unambiguity of the references with
   respect to versions and external profiling information,
   and a review of any interoperability or security
   considerations. The submitter may submit a revised
   registration or abandon the registration completely and
   at any time."

In order to move the proposal forward for the DITA TC,
someone or some designated group of TC members will need
to drive the effort, from a technical perspective, as the
content of the 2008 proposal is evaluated and updated.  I
will handle the matter administratively for the TC as an
act of registration, but technical issues -- including the
terms of the proposal, and responses to the IESG/community
reviewers -- will need to be resolved by the TC.

It would be useful if the TC can designate one of more
individuals to take responsibility for the proposal at
the technical level, where authority is given to make
decisions OR to escalate any questions to the plenary
TC per discretion.

I have appended a short list of additional resources [6]
that may be of interest or help to those who now become
involved in the rehistration process.

- Robin

Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
Staff bio: http://www.oasis-open.org/people/staff/robin-cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783

======== Resources:

[1] MIME type for DITA - RFC (approved by Technical Committee)
Tue, 10 Jun 2008 08:41:02 -0700

[2] subsequent discussion on the TC list

[3] Official mailing list used for review of registration proposals

ietf-types -- Media (MIME) type review
Info: https://www.ietf.org/mailman/listinfo/ietf-types
Archive: http://www.ietf.org/mail-archive/web/ietf-types/

[4] "Media Type Specifications and Registration Procedures"
Request for Comments: 4288
See "Registration Template":
See: http://tools.ietf.org/html/rfc4288#section-5.2

But we need to watch this revision of RFC 4288, which includes
a proposed slot "URI fragment/anchor identifier(s):" in
the "Additional information:" template field

Media Type Specifications and Registration Procedures
Obsoletes: 4288 (if approved)
September 5, 2011 (-01) or later
See "Registration Template"
 - See: http://tools.ietf.org/html/draft-freed-media-type-regs-01#section-5
 - Version -01 adds "URI fragment/anchor identifier(s):"

[5] Since DITA is now an OASIS Standard, and the (proposed)
"DITA MIME type" is referenced in DITA Specification v1.2
("B.3 DITA MIME type"), I suspect (don't know) the reference
to "Appendix B.3 DITA MIME type" would qualify as a valid
candidate for the "Published specification:", if this is
used in an Internet Draft designed to be approved as an
IETF Informational RFC.  In similar cases, the verbatim text
from a published spec is (re-)used in an Internet Draft,
or is excerpted and sent to the review mailing list.  In
the case of DITA v1.2 Appendix B.3 we don't have the
complete/proper proposal, so I think an independent I-D
(RFC) will be needed to support the "Preliminary Community
Review" process.

Its text:

Darwin Information Typing Architecture (DITA) Version 1.2
OASIS Standard
1 December 2010

"B.3 DITA MIME type
(Non-normative) It is common for Web-based services to establish
default actions for content based on the MIME type value sent in
HTTP headers. For example, the "text/html" MIME type is what
normally causes browsers to interpret the content of a web page
as presentation-oriented markup, verus "text/plain" which would
cause the markup to be displayed literally. A DITA MIME type
enables applications to recognize content as DITA to enable
special services such as semantically-informed search indexing
or on-the-fly rendering in the browser.

The OASIS DITA Technical Committee has requested the registration
of "application/dita+xml" with the IANA organization as the
formally recognized DITA MIME type. This process is in progress,
however the details are public so that implementors can make
early use of the proposed value.

More information about the proposal is documented in this note
of transmittal to OASIS for registration of the DITA MIME type:


[6] Additional resources

A. Lists of Registered MIME Media Types
 - http://www.iana.org/assignments/media-types/index.html
 - http://www.iana.org/assignments/media-types/application/index.html
 - TRAC: http://trac.tools.ietf.org/group/iesg/trac/report (active?)

B. W3C Commentary/Help (Date: 2011/06/21 13:35:30 or later)

This document describes how W3C Working Groups handle
registrations of Media Types, and it should be useful,
by analogy.

"Register an Internet Media Type for a W3C Spec"
* New Procedure: Registration template in spec, no RFC
* Old Procedure: Registration with an RFC
* Status of [W3C] Internet Media type registrations

C. XML Media Types and Registry

  Registry Name: IETF XML Registry

D. Endeavors to improve registration processes

The registration process administered by IANA through IESG
and IETF has come under review, and several efforts are
underway to help clarify and expedite the prosess for
various classes of registrations.  For example:

1. happiana -- IANA Registry Happiness, supporting
   discussion about streamlining and improving IETF
   (and other SDO) interfaces to IANA registration


2. Friendly Registries, as a workspace of a
   cross-IETF/W3C group whose aim is to make registries
   more usable for Web-related purposes - especially
   by non-"insiders"


To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dita-help@lists.oasis-open.org

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