Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5, wd11
    • Fix Version/s: wd12
    • Component/s: edits
    • Labels:
      None
    • Proposal:
      Hide

      Line 1047. The WD-12 level of the specification no longer mentions
      interoperation of Session Expiry with the Version 3.1.1 specification.

      Line 1442. WD-12 has no 0x9B return code other than on DISCONNECT.
      The server can set maximum on CONNACK, it can't change to
      not supporting it later on. Added a sentence to
      PUBLISH allowing the client to send 0x9B on DISCONNECT
      in response to an unsolicited PUBLISH with a QoS greater
      than its maximum.

      Line 1575. No change required.

      Show
      Line 1047. The WD-12 level of the specification no longer mentions interoperation of Session Expiry with the Version 3.1.1 specification. Line 1442. WD-12 has no 0x9B return code other than on DISCONNECT. The server can set maximum on CONNACK, it can't change to not supporting it later on. Added a sentence to PUBLISH allowing the client to send 0x9B on DISCONNECT in response to an unsolicited PUBLISH with a QoS greater than its maximum. Line 1575. No change required.

      Description

      WD11 Notes.

      Line 1047

      Non-Normative comment
      If the Client connects using this protocol, then reconnects using the MQTT V3.1.1 protocol using
      CleanStart 0 before the Session has expired, the Session state is kept indefinitely.

      PN: Hang on - this is either something that we require to happen (so it's normative) or it isn't,
      in which case it's out of scope for this spec. I would choose the latter.

      AB:I take your point. However, we have not said whether the state associated with the 3.1.1 client
      is the same state as that associated with the 5.0 client, and consequently what expiry interval it has.
      Leaving that open could lead to some divergent implementations.

      KB:This really is just one possible implementation of multi version support.
      It would make as much sense to say that a session is never shared between two versions of the spec.
      I would recommend dropping this comments,
      but as non-normative I do not care too much.

      Line 1442

      If a Server has not sent a Maximum QoS, and receives a QoS > 0 PUBLISH
      packet and that QoS level exceeds its capabilities it MUST reply with a
      PUBACK or PUBREC with the Return Code 0x9B (QoS not supported).
      In the case of QoS 2 messages, the Server MUST process the subsequent
      PUBREL packet and issue a PUBCOMP to complete the protocol flow.

      AB: This should go. The server should declare its maximum Qos on connect,
      not change its mind later.

      RG:Agreed that this paragraph should be deleted.
      Normative statements are not indexed for now.

      Line 1447

      Non-Normative comment
      A Client is not required to support reception or transmission of QoS 1
      or QoS 2 PUBLISH packets.
      If this is the case, the Client simply restricts the maximum QoS field
      in any SUBSCRIBE commands it sends to a value it can support.

      AB:This is not true if the publication is unsolicited.

      RG:This is also pointed out by Brian in MQTT-372 and the statement is very unclear.
      May be we should get rid of this as well.

      Line 1575

      If the Client sends a Request Response Information with a value 1,
      the Server MAY send the Response Information in the CONNACK.

      AB: There seems to be a lot pf scope for interoperability problems here.
      For example, if the clients uses this to form the reply to topic
      and the server does not send it or if the server has authorized
      a specific pattern for reply topics but the client does not request it.
      It seems like the server should simply mandate that the
      Reply Info is used whether or not it was asked for by the client.

      KB:The whole area of Reply Info is very ugly.
      However,
      this is the compromise which allowed us to complete Request/Response.
      The client may request it, and if so the server may respond with it,
      and the contents are not defined other than being a string.
      We can change the words if that would help,
      but changing the concept is a core change.

        Attachments

          Activity

            People

            • Assignee:
              Andrew_Banks Andrew Banks
              Reporter:
              Andrew_Banks Andrew Banks
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: