The application/sql Media Type
draft-shafranovich-mime-sql-06

[Ballot comment]
The charset text (and the encoding text) has changed significantly since media-types review and Last Call. It looks good to me, but should likely be at least checked by some sort of expert review.

[Ballot discuss]
[Updated to remove the bit about encoding. The author has convinced me that I was wrong about that one.]

I'm concerned about the following:

  Optional parameters:

      "charset" - indicates the character set to be used.  When not
      specified, a default value MUST NOT be assumed.

      Implementators should be aware that SQL may carry character set
      information in-band.  In such cases, the "charset" parameter
      SHOULD NOT be used.  In cases, where no character information is
      supplied in-band, implementors SHOULD use the "charset" parameter,
      if possible.

- As far as I can tell, the above has been changed significantly since the last posting to the media-types mailing list, and since IETF Last Call, and the current text does not seem to be responsive to the LC review. So it's not entirely clear that the current text has been reviewed. There is nothing in the writeup or the document explaining. Please explain.

- I don't see why the charset is a SHOULD NOT instead of a MUST NOT if the character set information is in-band. At the very least, if the character set information is in-band, the charset MUST be identical to the in-band character set, but I think it's actually dangerous to put the charset on at all if there is an in-band character set. And none of this accounts for the comment during LC that there is also an *out-of-band* character set.

[Ballot discuss]
I have one very small concern that I am raising as a discuss but should be easily cleared with a short editor's note.

The text:

"Being that SQL is a full fledged programming language and may
include embedded source code for other programming languages, it
may be used to transfer malware...."

looks like it gives permission to use the method to distribute malware, which is not the intent of the authors.

Some words of the form "there is a risk of malicious applications attempting to use ...."  would clarify the matter.

[Ballot discuss]
I'm concerned about the following:

  Optional parameters:

      "charset" - indicates the character set to be used.  When not
      specified, a default value MUST NOT be assumed.

      Implementators should be aware that SQL may carry character set
      information in-band.  In such cases, the "charset" parameter
      SHOULD NOT be used.  In cases, where no character information is
      supplied in-band, implementors SHOULD use the "charset" parameter,
      if possible.

  Encoding considerations:

      If the "charset" parameter is used, the corresponding 7-bit, 8-bit
      or binary encoding may be used.  If the "charset" parameter is not
      used, binary encoding may be required.

- As far as I can tell, the above has been changed significantly since the last posting to the media-types mailing list, and since IETF Last Call, and the current text does not seem to be responsive to the LC review. So it's not entirely clear that the current text has been reviewed. There is nothing in the writeup or the document explaining. Please explain.

- I don't see why the charset is a SHOULD NOT instead of a MUST NOT if the character set information is in-band. At the very least, if the character set information is in-band, the charset MUST be identical to the in-band character set, but I think it's actually dangerous to put the charset on at all if there is an in-band character set. And none of this accounts for the comment during LC that there is also an *out-of-band* character set.

- I cannot figure out how, in practice, a binary encoding will work with a charset parameter. A charset is supposed to convert a sequence of octets into characters. What is the difference between 8-bit and binary with a charset parameter? It still must be dealt with as 8-bit to convert the octets to characters.

[Ballot comment]

I think there are some security considerations covered
in RFC 4329 (closest thing to this I saw in the
registry) that might be usefully included here.  You
could take a look at that and see if there are things
worth mentioning. (You could refer the reader to 4329
but that's different enough that a simple reference
might not be so useful.)

The points about input/output and data URIs seem worth a
mention in particular, but I'd really encourage the
authors to see what they think since I'm not really sure
how application/sql would be used and I'm sure the
authors know more about that.

IESG/Authors/WG Chairs:

IANA has reviewed draft-shafranovich-mime-sql-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

This document, upon approval, requests adding a single media type to the applications media type registry located at:

http://www.iana.org/assignments/media-types/application/index.html

The media type to be added are:

sql

Currently the application media type library is maintained through expert review as defined in RFC 5226.  We have initiated a request and sent it
to the designated expert for review.

We understand that the addition of the new media type is the only action required of IANA upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The application/sql Media Type) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The application/sql Media Type'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document registers the application/sql media type to be used for
  the Structured Query Language (SQL).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-shafranovich-mime-sql/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-shafranovich-mime-sql/ballot/


No IPR declarations have been submitted directly on this I-D.

Document shepherd writeup, using the experimental template:
http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate

1. Summary

Barry Leiba is the responsible AD, and is serving as the document
shepherd.

This document registers the application/sql media type to be used
for the Structured Query Language (SQL).  It is a simple,
Informational document that merely does the IANA registration in
the Standards Tree, according to
draft-ietf-appsawg-media-type-regs.

2. Review and Consensus

The document has been reviewed on the media-types mailing list,
as specified in draft-ietf-appsawg-media-type-regs, and the
author has made the changes suggested in reviews there.  The
media types Designated Expert was one of the reviewers.  There
are no known objections to this registration.

3. Intellectual Property

The author has stated that to his direct, personal knowledge,
there is no IPR related to this document.

4. Other Points

None.