[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-414) Notes copied from WD11.
[ https://issues.oasis-open.org/browse/MQTT-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Raymor updated MQTT-414: ------------------------------ Affects Version/s: 5 > Notes copied from WD11. > ----------------------- > > Key: MQTT-414 > URL: https://issues.oasis-open.org/browse/MQTT-414 > Project: OASIS Message Queuing Telemetry Transport (MQTT) TC > Issue Type: Bug > Components: edits > Affects Versions: 5, wd11 > Reporter: Andrew Banks > > 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. -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]