Proposed DNP note for draft-tegen-smqp-10.txt

[ned.freed@mrochek.com]

The IESG believes that draft-tegen-smqp-10.txt is unsuitable for publication in
its present form. The protocol specified by this document is seriously deficient
in a large number of ways, including but not limited to:

(1) The claims for this protocol seem overly broad. In particular, the
    document says "A single transaction  protocol can be used where currently
    many different protocols are  current being used (both open and
    proprietary)." The underlying assumption is that the message queue and
    publish/subscribe aspects of various protocols are sufficiently
    independent of the protocol they are embedded in that they can be teased
    out into a separate protocol. This may be possible in some cases, but
    certainly not all.

(2) Aside from saying that the client may be able to infer the version of
    the protocol from the banner, there appears to be no way for a client to
    determine the capabilities of a given server. The lack of a well defined
    capabilities negotiation mechanism is a serious omission in a protocol
    of this complexity.

(3) A specific case where the lack of a capabilities announcement scheme 
    is an issue is that there appears to be no way for the client to
    determine the set of authentication mechanisms the server supports.

(4) The authentication needs of this protocol could easily be met by SASL
    (RFC 2222). Instead this defines its own private authentication framework,
    which is needlessly complex and which cannot reuse existing defined
    SASL mechanisms easily.

(5) There appears to be no mechanism specified to provide privacy protection
    for the protocol as a whole using TLS/SSL or some similar facility.

(6) A "content-encryption" field is mentioned as a means of encrypting
    content but the specifics of this field are never given. Moreover, the
    field isn't aligned with existing content security schemes based on
    security multiparts. Nor is any description given of how agents are
    supposed to acquire the keys they would use to secure the content they
    send or receive.

(7) Rather than reference the MIME specification's definition for data object
    labelling, this specification reiterates some MIME facilities but not all,
    and does so in incompatible ways. For example, the content-type field
    appears to allow specification of only a media type, which would imply
    that media type parameters are not allowed. Or consider MIME-Version,
    which is given major/minor versioning semantics here, something the
    base MIME specification deliberately does not do.

(8) The protocol appears to use HTTP's content-encoding facility but
    nowhere is this fully defined or specified.

(9) The document acknowledges that control of access to various topics and
    queues is essential and states that access control lists are to be
    used to provide this control. Yet the document fails to fully specify
    the semantics of such lists, opting instead to simply describe a set of
    per-topic/queue parameters to be used to control access. The two schemes
    are not necessarily equivalent, and experience with other protocols
    has shown that failure to specify a clear access control model often
    leads to serious interoperability problems later.

(10) The specification fails to address the issue of quotas and other limits
     that would need to be imposed to prevent service denial attacks.

(11) Congestion control issues are not addressed.

(12) Some error conditions do not appear to be covered in the list of defined
     error codes. For example, an attempt to unsubscribe when no subscription
     exists would warrant a specific error yet no appropriate error appears to
     be defined.

There are also several structural document issues that would need to be
addressed prior to publication:

(1) The document redefines a subset of ABNF instead of referencing the
    existing ABNF specification (RFC 2234).

(2) There is no IPR statement, and given the space this document is in one is
    definitely needed.

(3) The MD5 and KERBEROS authentication mechanisms are mentioned but never
    defined.

(4) Much of the ABNF given in the document appears to be incomplete or
    incorrect. For example, the production for the greeting banner is a ABNF
    fragment rather than a production, the productions for media-type
    and content-coding are never specified, the definition of the
    notation appears to call for "name = value" syntax but subsequent
    sections use BNF "name ::= value" notation, and the daytime production
    is specified but never used.