1. Summary
Murray Kucherawy is the document shepherd.
Barry Leiba is the responsible Area Director.
This document registers the text/markdown media type for use with
Markdown, a family of plain text formatting syntaxes that optionally
can be converted to formal markup languages such as HTML.
The working group has selected Informational status since the markdown
syntax was specified outside of the IETF, and RFC6838 does not require
Standards Track status for a document from the IETF stream registering
a media type.
2. Review and Consensus
The document had fairly active review within APPSAWG at first, but
suffered from some attrition along the way. Feedback ranged from
"Why does the IETF need to do this?" to whether the entire work
(this plus the use-cases document) should appear in a single document
or in separate documents. For the latter question, the split was done;
for the former, there are still one or two participants who are unclear
whether this media type or the registries created here will ever be used
by someone other than the author.
Still, there was enough critical mass to get it through a Call For Adoption
and enough reviewers, including both the usual suspects and some outside
participants, that the chairs chose to proceed.
The document evolved over time, being whittled down quite a bit from the
earliest proposals. The version being sent to the IESG appears to be
minimalist, which is what the WG wanted.
The author and chairs were implored to be sensitive to the markdown community,
which is external to the IETF. I'm satisfied that this was done as much
as practical.
No particular directorate review is critical here, though the usual ones
should still be done. The media type reviewer is aware of the work and
has not voiced any objection to the working group, though no specific
request was made for early review either.
The author asserts that he and others have already begun to use the
media type in prototype form within open source and commercial products.
3. Intellectual Property
The author has confirmed that he knows of no outstanding IPR claims, and
thus submits the draft in full compliance with BCPs 78 and 79.
4. Other Points
There are three references to non-IETF URLs in the Normative References.
There is also a normative reference to RFC3778, which is Informational, and
not currently in the DOWNREF Registry.
The IANA Considerations section was checked and needs the following change:
OLD
All references (including contact information) MUST be verified as
functional at the time of the registration.
If a registration is being updated, the contact information MUST
either match the prior registration and be verified, or the prior
registrant MUST confirm that the updating registrant has authority to
update the registration. IANA is to send an email to each old and new
address confirming the change request. The emails are to contain a
nonce (which may be embedded in a URI) that, when return by email or
another mechanism (e.g., HTTP), serve to verify the request. An
affirmative response from any of the addresses (old or new) is
sufficient. If neither the old nor the new registrations contain any
email addresses, then the update MAY succeed without email
confirmation. Therefore, registrants are encouraged to list at least
one email address for registration protection.
As a special "escape valve", registrations can be updated with IETF
Review [RFC5226]. All fields may be updated except the variant
identifier, which is permanent: not even case may be changed.
NEW
All references (including contact information) are expected to be
valid at the time of the registration.
All fields may be updated except the variant
identifier, which is permanent: not even case may be changed.
Nothing else of note.