[OASIS Issue Tracker] (MQTT-277) Comments on Message Metadata WD2

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

     [ https://issues.oasis-open.org/browse/MQTT-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Borgendale updated MQTT-277:
--------------------------------

    Description: 
1) line 93: Summary of requirements

Requirements 1 and 4 seem to conflict and I think neither of them is good.  What others have done in this area and which we should emulate is that there are three classes of metadata:
- That which is fully defined in its syntax and semantics
- That which we assign a purpose without specifying how to act on it
- That with is reserved for private use 

-For example, if we define message expiration as metadata, we define what it means and how it should be processed.  On the connection we have the username metadata which we assign a name, but do not define what use is made of it by the server.  If a client or server uses it own conventions, it should be easy to separate this from assigned metadata and adding new assigned metadata should not cause a conflict with private use.

Requirements 5 and 10 also seem to be in conflict.  A better statement for #5 is that a server must not remove any metadata it does not understand.  There should not be any requirement on the client.  This also deals with #10.  If a server understands the meaning of the metadata, then it can make a decision to remove or modify it.  If it does not understand the metadata it is required to pass it on.

2) This document is limited to metadata attached to messages, but in fact there are at least three objects which would rationally have metadata:
- Connection
- Subscription
- Message

The current username and password can really be thought of as connection metadata.  The MQTT spec does not really say what is done with these field, just that they optionally exist.  What happens due to only having these two is that we overload them.  So if I need 4 values to authenticate a connection, I create complex objects within username and password.

A similar thing happens today within Subscription where the only specified items are the topic filter and QoS.  If I need more information to complete a subscription then I would need to overload the topic filter.


> Comments on Message Metadata WD2 
> ---------------------------------
>
>                 Key: MQTT-277
>                 URL: https://issues.oasis-open.org/browse/MQTT-277
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: MessageMetadata
>            Reporter: Ken Borgendale
>
> 1) line 93: Summary of requirements
> Requirements 1 and 4 seem to conflict and I think neither of them is good.  What others have done in this area and which we should emulate is that there are three classes of metadata:
> - That which is fully defined in its syntax and semantics
> - That which we assign a purpose without specifying how to act on it
> - That with is reserved for private use 
> -For example, if we define message expiration as metadata, we define what it means and how it should be processed.  On the connection we have the username metadata which we assign a name, but do not define what use is made of it by the server.  If a client or server uses it own conventions, it should be easy to separate this from assigned metadata and adding new assigned metadata should not cause a conflict with private use.
> Requirements 5 and 10 also seem to be in conflict.  A better statement for #5 is that a server must not remove any metadata it does not understand.  There should not be any requirement on the client.  This also deals with #10.  If a server understands the meaning of the metadata, then it can make a decision to remove or modify it.  If it does not understand the metadata it is required to pass it on.
> 2) This document is limited to metadata attached to messages, but in fact there are at least three objects which would rationally have metadata:
> - Connection
> - Subscription
> - Message
> The current username and password can really be thought of as connection metadata.  The MQTT spec does not really say what is done with these field, just that they optionally exist.  What happens due to only having these two is that we overload them.  So if I need 4 values to authenticate a connection, I create complex objects within username and password.
> A similar thing happens today within Subscription where the only specified items are the topic filter and QoS.  If I need more information to complete a subscription then I would need to overload the topic filter.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)