Shepherd writeup

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:

   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.

   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.