Re: Experimental RFC to be: draft-tegen-smqp-10.txt

[The IESG <iesg-secretary@ietf.org>]

To the RFC Editor:

The IESG recommends that SMQP: Simple Message Queue Protocol 
<draft-tegen-smqp-10.txt> NOT be published as an Experimental RFC.

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.

Thank you,

The IESG Secretary