## 5 Group Communication Using Unicasts
### Validation Process  
Whenever a client requests to create a new entity or to modify an existing entity, the EM performs a validation process. The purpose of this validation process is twofold:  
1. Make sure that the members in the entity exist and can be used. 2. Derive the properties of the entity based on the properties of the members it contains. If the entity successfully passes validation the EM marks the entity as a valid entity and stores the entity along with its calculated properties in the entity database for future usage. If the entity fails  
Figure 7: A CoAP client requesting from an Entity Manager (EM) to create a new entity that contains two resources. validation it is still created, but marked as invalid. The entity validation is based on EM's knowledge of the individual members and their profiles and based on the knowledge in the capabilities database as will be discussed in the next paragraphs. Resource profiles can be used to express capabilities of a CoAP server and its resources [25]. Profiles are usually expressed in JSON format [26]. To briefly illustrate resource profiles, let us assume that in Figure 7 the temperature sensor at \"coap://[sen5]/tmp\" supports the \"Uri-Host\" (3), \"ETag\" (4), \"Observe\" (6), \"Uri-Port\" (7), \"Uri-Path\" (11) and \"Content-Format\" (12) CoAP options (op). This sensor further supports the \"application/json\" (50) content format (cf) and the allowed method (m) is GET (1). This will result in sen5 having the following profile:  
Res: 2.05 Content (application/json)  {  \"profile\":{  {  \"path\":\"tmp\",  \"op\":[3,4,6,7,11,12],  \"cf\":[50],  \"m\":[1]  }  }  }  
If the Entity Manager does not know any of the members in an entity (e.g., based on knowledge in a resource directory) or does not know the member capabilities, it tries to obtain this information according to a fallback mechanism as follows:  
1. The EM tries to contact the object containing the resource in order to obtain the resource profile, since this returns the most complete information about the resource. 2. If the resource profile does not exist, the EM tries to derive information about this resource from /.well-known/core of the respective object. 3. If this fails as well, the EM tries to query the resource directly to discover, as a minimum, if the resource exists or not. The validation process that the Entity Manager performs on entities is shown in a simplified form in Figure 8. In essence the process will:  
* Verify whether the individual members contained in the entity are valid (_i.e._, the resources exist on the respective nodes). * Derive the operations that can be performed on the entity, based on the operations supported by the individual members (e.g., which CoAP options are supported, which RESTful methods are allowed?). * Verify whether the individual members do not conflict. A sample conflict can occur when an entity creation request contains a sensor member that supports only the GET method and an actuator member that supports only the PUT method. * Verify whether the responses sent by the individual members can be combined together using a common denominator or knowledge from the capabilities database. Once the EM knows all information about the members that should become part of the entity and once all necessary checks have been passed, the EM creates a profile for the entity based on this information and the EM's capabilities database. To illustrate this let us further assume that the second temperature sensor in Figure 7 \"coap://[sen8]/tmp\" supports the same options as sen5 except for the observe option. Only the GET method is allowed and the supported content formats on this sensor are \"text/plain\" (0) and \"application/json\" (50). Thus sen8 will have the following profile:  
```
Res:2.05 Content(application/json) { \"profile\":[ { \"path\":\"tmp\", \"op\":[3,4,7,11,12], \"cf\":[0,50], \"m\":[1] } ] }
```  
Based on these two profiles the EM constructs a profile for the newly created entity.