"XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains."
This sounds like text from 1997 (XML was finalized in 1998). I don't think there is any need in this document to explain how widely XML is used.
Response: Deleted the whole thing
"XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring ..."
XML is not expanded on first use, WWW is in the expanded form, URI is not expanded. I suggest looking up abbreviation guidelines to see what needs to be expanded and what can be used in abbreviated form.
Response: Deleted the whole thing, but note that XML is expanded in the previous sentence
In the Intro, paragraphs can either be shortened or just removed. In particular, the paragraphs starting with "Although XML is a subset of the Standard Generalized Markup Language" and "Since XML is an integral part of the WebDAV Distributed Authoring Protocol" can just be cut. These were important for RFC 3023, in order to convince people who might not have heard about XML, or may not have known that the IETF was already using XML (in WebDAV), or confused it with SGML, but these days, that's not a problem at all.
Response: Deleted middle three paras, adjusted final para as a result
"Similarly, XML has been used as a foundation for other media types, including types in every branch of the IETF media types tree. To facilitate the processing of such types, media types based on XML, but that are not identified using application/xml (or text/xml), SHOULD be named using a suffix of '+xml' as described in Section 8."
The RFC 2119 SHOULD is defined after that. I suggest removing the "SHOULD" and leaving it to Section to specify how such media types are named.
Response: reframed, with no 'SHOULD' and a reference to 6838
In section 3 (XML Media Types), a lot of work is needed to disentangle what readers need to know (think about readers in 5 or 10 years) on the one hand, and rationale and historical background on the other hand (which becomes less and less important when moving to the future). The paragraph starting with "Within the XML specification", for example, several times switches between actual spec text (MAY/MUST/...) and notes.
Response: major restructuring
I suggest rewriting the second paragraph in that section to separate the notes from what is being specified. It took me some time to understand that part of the draft.
Response: major restructuring
Section 3.1, application/xml Registration: The text about the optional charset parameter is way too long to stay in this registration, and is referenced from many other places. I'd separate it out into a separate section, and just put a pointer to that section from the template. Again, as elsewhere, sort out the normative stuff from the rationale/history.
Response: New section created, merging various bits and restructuring internally
"If users would like to rely on the encoding declaration or BOM and to hide charset information from protocols, they SHOULD determine not to use the parameter."
I don't understand the above. What is being recommended?
Response: reworded to clarify, removed 2119 language
Section 3.6: A Summary is a good idea in a descriptive text, but putting additional MUSTs there is a bad idea. This probably just shows that the text up to here wasn't able to capture some essentials, which should be fixed at the source, not cleaned up afterwards with a summary.
Response: removed
What is the summary in Section 3.6 for?
Response: removed
"When the syntax of a fragment identifier part of any URI or IRI with a retrieved media type governed by this specification conforms to the syntax specified in [XPointerFramework], conformant applications MUST attempt to interpret such fragment identifiers as designating that part of the retrieved representation specified by [XPointerFramework] and whatever other specifications define any XPointer schemes used."
I read the "MUST attempt" as "give it a try". I suggest rewriting the sentence to make the RFC 2119 requirement clear.
Response: "attempt to" removed.
"A registry of XPointer schemes [XPtrReg] is maintained at the W3C. Unregistered schemes SHOULD NOT be used."
It would be easier to recommend that the schemes which are used are to be registered.
Response: I've added that, but left the above, slightly clarified, as it's a requirement on document authors, whereas the addition as you suggest is a requirement on scheme authors.
Section 8: Same problems all over again. There is a lot of justification for why "+xml" may be needed. This may have been appropriate when the idea of a +xml suffix was first introduced, but that was 10 or more years ago.
Response: Considerable material removed
Suggest to remove the recommendation to register media types with +xml suffix. Suggest to add recommendation for a 'profile' parameter for application/xml, as is being done for atom : http://tools.ietf.org/html/draft-wilde-atom-profile-01
Response: Not done, see extensive discussion on apps-discuss
Suggest to remove discussion of hypertext linking. XML does not include hypermedia affordances, so there is a disconnect between what can be expected in application/xml vs. what is discussed in this RFC. If an XML vocabulary contains XLinks, let that vocabulary register its own media type. Also, relative to the discussion of XLinks in that section, the web is not limited to XML documents (heck they hardly even exist on the web), so perhaps XLink itself needs an update to allow linking to non-XML representations.
Response: Removed along with enclosing list
8.1: It would be great if this document provided a template for +xml registrations, with the usual pointers already filled in (and lots of [add/change as appropriate] or so notices).
Response: Will do, in a subsequent draft, after discussion as to which is most suitable starting point
"If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity MUST be encoded in quoted-printable or base64."
This RFC 2119 requirement is also in Section 3.1 and Section 9.4.
Response: Not sure what you are suggesting here?
Similar problems in the security section, for example this piece of text: Use of XML is expected to be varied, and widespread. XML is under scrutiny by a wide range of communities for use as a common syntax for community-specific metadata. That was 10 or 15 years ago. Please let's rewrite this.
Response: Two paras removed, and some clarification added: please review
Removing the current Appendix A and pointing to it in RFC 3023 is the first and biggest step. I didn't realize this, but currently, RFC 3023 is listed as normative, which is really strange.
Response: removed, with a brief explanation
Suggest to remove reference to Appendix A. Remove Appendix A, also. All of that stuff is not the business of this RFC, but is the responsibility of the registration procedure, in my opinion.
Response: removed, with a brief explanation
I found it difficult to identify the (RFC 2119) recommendations and requirements as they appear in several parts of the draft (re: comment about Section 9.12). I suggest making the text crisp. This could be done by reformatting some parts of the draft (e.g. see comment about second paragraph of Section 3.1). By the way, an "Obsoletes" for RFC 3023 should be added. There is a school of thought about not making any normative statements in examples. It could be said that examples are to be used sparingly as it distracts the reader from what is being specified.
From the Abstract I read that the purpose of the draft is:
I suggest having that as the focus for the draft. I understand that it is difficult to make changes for a -bis. I would consider that for this draft for document clarity (see Grace Hopper)
Response: I've made a number of changes to try to address this, including a note at the top of the Examples section. Should we go further and move it to an appendix?
Please update the reference for 8BITMIME to RFC 6152.
Response: done
There are a lot of normative references in this draft. Why is, [PNG], for example normative? I suggest going through the references to see what is needed and what could be moved to Informative (if the reference is still relevant).
Response: done