1662 Associate Response
- Created
- 29 Aug 2019
- Status
- In Force (green)Closed: the solution is part of the standard. No further comments are taken. Show the workflow
- Batch
- 57/2673/INFThis tissue went out with this batch, which was closed on 01 Apr 2024.
- Part
- Part 8-2 (2018)
- Links
- None
- Page
- 63
- Clause
- 10.2.2.1.1
- Paragraph
Issue
InitiateResponsePDU does not contain an AssociationID (MMS InvokeID). See example response in figure 20 of the 8-2 standard. How should a possible client know under which AssociationID it is run on a connected server? How is it intended to exchange this information and which XML element must be used?
Proposal
| Discussion | Created |
|---|---|
| Must Implement As per 57/2445/INF Released batch 2 of TISSUEs | 28 Aug 24 |
| In Force (green) Batch '57/2673/INF' (2) closed | 01 Apr 24 |
| Solution Accepted Review and correct/clarify document text | 07 Nov 23 |
|
Ballot Period
On behalf of B. Bony:
Management of the AssociationID is not specified by the part 8-2 but rather in IEC 62351-4. The AssociationID value is build during the Associate request/response handshake and the XML attribute assoID transporting it is within the direct child element of the XMPP stanzas as described in IEC 62351-4. As mentioned in Note 1 of clause “9.1 General”, the elements describing the AssociationID and the E2E security mechanism are not described in the present document. See also Clause “5.2.2 XML payloads” explaining which part of the payload is specified in part 8-2 versus IEC 62351-4. |
11 Sep 19 |