Search code examples
onem2m

Should the oneM2M AE-ID attribute of the AE resource always be represented as SP-relative or absolute, not CSE-relative?


If an AE registers with a CSE and gets assigned a C-AE-ID-Stem, should the AE-ID attribute of the new AE resource (as is received in the payload of the AE Create Response for instance) be the C-AE-ID-Stem, or the SP-relative-AE-ID?

Since the registration request itself, and subsequent requests from the AE to its CSE, are within the local CSE domain, a CSE-relative AE-ID is fine. But if the AE wishes to use its AE-ID in a context outside of its CSE context, it needs the SP-relative (or absolute) version.

The specification doesn't seem to be clear on this specific point, though I did find this: in TS-0004 6.2.3 "oneM2M Entity Addressing", it defines "AE-ID" this way:

AE-ID = absolute-AE-ID / SP-relative-AE-ID / S-AE-ID-Stem

From that, I think you could argue that the AE-ID attribute of the AE resource cannot be a C-AE-ID-Stem, in any context. Is this thinking correct?

For example, if a CSE with CSE-ID of /mycse registers an AE with C-AE-ID-Stem of Cmyae, can (or should) the AE Create response look like this:

{
  "m2m:ae": {
     "aei": "Cmyae"
  }
}

Or should it be this:

{
  "m2m:ae": {
     "aei": "/mycse/Cmyae"
  }
}

Solution

  • You are right that the AE-ID can have any of the forms you mentioned, ie. CSE-relative, SP-relative, and Absolute. But those are defined for the context the AE-ID is actually used in: within the registrar CSE, the service provider domain, or even outside the service provider domain.

    You may have a look at TS-0001, clause 7.2 "Identifier Formats". In the rather big table 7.2-1 in that clause there are the definitions for the AE-ID format for the different contexts.

    An important part of the specification are the lines below that table that explain that not the AE but the CSE is responsible to do the conversion of identifiers when a request leaves, for example, a CSE-relative context (emphasis by me):

    The format (i.e. CSE-relative, SP-relative or absolute) of resource identifier (e.g. the To parameter, accessControlPolicyIDs attribute) shall be correctly set by the Originator in an initial request, while the format of AE-ID or CSE-ID in the From parameter shall be set in a shortest format by the Originator in the initial request and it shall be converted in another format by the Registrar CSE or IN-CSE as the following.

    When an AE is the Originator, the From parameter shall be in AE-ID-Stem. When the Registrar CSE receives the request, it shall convert the format into SP-relative AE-ID in case the stem is CSE-relative and the To parameter refers to a resource hosted by a different CSE.

    When an CSE is the Originator, the From parameter shall be in SP-relative CSE-ID.

    The IN-CSE shall convert the format of the From parameter in a request that is received from SP-relative to absolute if the To parameter refers to a resource is hosted by a CSE in a different M2M Service Provider Domain.

    Also, see TS-0001 clause 7.1.2 "Application Entity Identifier (AE-ID)":

    The AE-ID, when used in the context of a specific CSE where the AE is registered, it is sufficient to be unique within the scope of that specific CSE. It is extended to become M2M Service Provider unique when used outside such specific CSE.

    Im other words: The AE-ID attribute contains an identifier in CSE-relative format. The AE uses this identifier in its shortest form, e.g. for the originator, when sending requests via its registrar CSE, but the registrar CSE must extend it when, for example, forwarding the request to another CSE.