[OASIS Issue Tracker] (MQTT-414) Notes copied from WD11.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ 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)