SDS-2025-0017R04-ogc_ipe_configuration_aspects_supl
Coversheet | Value |
---|---|
Meeting ID | TP#68 |
Work-item | WI-0100 |
Reason | wordings & revision |
Merge request reports
Activity
requested review from @neubachera
assigned to @neubachera
1.) The IPE should rather register an AE and not create
2.) triggered instead of triggert
3.) make clear that the IPE has two container on for incoming one for outgoing. (thats implicit in the text)
Edited by Ingo Frieseissues to be fixed:
-
notification is no resource
-
after <> needs to be the term "resource"
-
The IPE has to be a AE itself, needs to be added
-
container does not need to be under an AE
Remarks: It might be in,but there was still discussion about container , are there two different?
The second flow diagramm might be divided and then we have one for the container (where ever it exists (under the cse or under the IPE-AE) and the AE registration
-
added 22 commits
-
6497c19c...567aed94 - 21 commits from branch
R5
- 838feba1 - Merge branch 'R5' into 'SDS-2025-0017-ogc_ipe_configuration_aspects_supl'
-
6497c19c...567aed94 - 21 commits from branch
Remarks from SDS#69 session on 1st of April
- resolve format issues
- HTTP is to specific because also other protocols might be used. Take 200 HTTP status code out
- its called varification not validation (in the figure)
- shall not must
- notify message is optional (see TS-004 7.3.1) the notficationURI should be reference the AE-Resouce ID because a single URI was once ment to send notifications outside the oneM2M eco-system
Could you make the following changes please?
- In 6.3.2.0 you currently have
Furthermore the pointOfAccess (poa) attribute of the
<AE>
resource may be set to the address of the IPE where it can receive notifications from the CSE. Alternatively the notificationURI attribute may be set in the<subscription>
resource creation request described in clause 6.3.2.1 .These are not alternatives. You have to set the notificationURI attribute in the
<subscription>
resource. The only choice is whether you want to use oneM2M protocols to send the notification to the IPE (in which case you set the notificationURI to the<AE>
resourceID), or whether you use some other mechanism, in which case you set the notificationURI to the URI used by that mechanism. I think that you should require the former, which means that you need to say that:- The
<AE>
shall have requestReachability set totrue
- The
<AE>
shall have a pointOfAccess attribute giving the protocol and address that the IPE is going to use to receive notifications from the CSE.
- In 6.3.2.1 you currently have
A
<subscription>
resource shall be created under this<container>
resource. During its creation, a verification notification request is sent to the IPE. The IPE must respond with an HTTP status code of 200 and a oneM2M response status code of 2000. If no pointOfAccess (poa) attribute is set in the<AE>
resource, the notificationURI attribute in the<subscription>
resource creation request shall be set to the address of the IPE.- You should say here that when the subscription is created its notificationURI shall be set to the IPE's
<AE>
resourceID. - The second sentence should say 'a verification notification may be sent to the IPE' rather than shall be sent since the hosting CSE is not required to send one.
- Consequently the third sentence should start 'If it receives a verification request, the IPE shall ...
- The third sentence must not mention HTTP since the protocol used is specified by the pointOfAccess in the
<AE>
and might not be HTTP. I would say 'If it receives a verification request, the IPE shall check the validity of this request and then reply with a oneM2M response containing a Response Status Code indicating "OK".' - Delete the fourth sentence, since the pointOfAccess is always required (this is now covered in 6.3.2.0)
- Please change validation to verification in this sentence:
- The hosting CSE evaluates the request and performs the appropriate checks, including validation that the notification endpoint of the IPE is available. It then creates the
<subscription>
resource.
- You have a sentence about handling the actual notifications when they come in
Since the IPE has subscribed to this
<container>
resource it receives a notification message along with all attributes of the<contentInstance>
resource when new data arrives. Do you say anywhere what it does with this notification message when it arrives? It needs to check the validity of the notification, e.g. to check that it does come from the subscription that it created and isn't a spam message. Or are you planning to handle Security somewhere else in the TS.- There are a few places where you use the phrase "result message". In oneM2M we call this a Response or Response primitive.
-
delete double word "the"
-
Since the notificationURI in the Subscription is an AE resourceID no verification takes place. So take out all verification aspects
Edited by Ingo Friese-