Section 6 "Resource Discovery" improvements

[zach@…]

The following improvements should be made to Section 6:

• Explain the m-DNS naming stuff in more detail with an example.

• If URIs are encoded using e.g. 7-bit ASCII encoding, should this HTTP Link Header format also be? Would be 15% more compact...

• Comment on the example from Carsten: These are two generations from the link-value production. How are these fit together? CRLF? We need a top-level production.

[zach@…]

Further improvements to Section 6 in order to optimize multicast resource discovery:

• Add URL query string support for resource description variables. If a query string exists in the /.well-known/resources URL then a response is sent only if/with exact match of those variables. For example /.well-known/resources?name=Temperature would only return resources with name=Temperature.

• Reduce the overhead of the attribute names in the format. Use maximum 2 letter attributes such as nm (Name), ct (Content-type), sh (short URL) etc.

• Rules for answering multicast requests to ensure that error messages are not returned. This should be done for all multicast requests, not only discovery ones.

• Assign a short URL for /.well-known/resources such as /r (matching the short URL scheme in coap-01, whatever it is). The short URL scheme itself may also need an attribute.

• Improve the description of each attribute in the text.

• Include message exchange examples and different use cases.

[zach@…]

Now included for coap-01. Still doing a detailed analysis and checking that we have taken all the SE2.0 requirements and scenarios into account before submission.