* Section 2 - I would like more clarification on the subject as being derived implicitly from the armor and is a single entity rather than multiple entities. If we think that we want to do multiple subjects then that needs to be discussed.
* Section 2.1 - The model does not current deal with the question of queries and how they would be permitted for a non-query object. * How do we ant to look at doing the generalization for the structure provided. There are two things to look at: 1. The object identifier: It makes sense for a good many things for this to be an absolute-path. However for other things this would be some type of identifier. With both the GroupKDC and with MQTT this identifier is a string. In the MQTT case the string has defined wild card behavior. Part of the question is how much does the object naming scheme need to be identified to the client, the AS and the RS. 2. The permissible actions: For a coap addressed device, it makes sense for this to be based on the set of coap verbs and the compressed bit string makes a great deal of sense. However for both GroupKDC and MQTT these verbs are not the same and thus cannot be compressed in the same manner. What I would like to see is a structure defined that can be used in a number of situations, but which the details are going to be very object dependent. authorization-info = [ * authorization] authorization = [ object: object-identifier, permissions: [* permission-name] | uint .bits methods ] permission-name = tstr One option would be to allow the methods to be object dependent this means that you could have "methods = &( PUBLISH: 0, SUBSCRIBE: 1)" for the MQTT case. The advantage of this is that it provides better compressions, but it also means that one needs to know what the enumeration is for each different type of object. I don't know if this means that one needs to start having a registry to deal with people adding verbs to a particular interface. I also don't know what it would mean if they were interface specific and an object supported two different interfaces. Nits: Section 2 - para 2 s/on object/an object/ Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
