ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Superannuation Profiles
- From: "Pim van der Eijk" <pvde@sonnenglanz.net>
- To: <ebxml-msg@lists.oasis-open.org>
- Date: Wed, 2 Jan 2013 15:23:43 +0100
Hello,
In the last call we
discussed a few questions of the Australian Tax Office on their profiling
of ebMS3/AS4. Since I am working on similar topics, I've had
another look at them, here is some more detailed feedback:
1) use of Pmode.ID
and AgreementRef.
As it was explained
to us, ATO have identified several sub-profiles and want parties to be
able to select, in a message, which specific sub-profile a message
initiator is using. To do this, they define
default agreements (chapter 5 of their "Message Orchestration and Profiles"
document http://www.ato.gov.au/download.asp?file=/content/downloads/SPR_00335171_Attach7.pdf)
with specification values for several PMode parameters (Appendix in same
document). Two values they are setting in this way are the
AgreementRef and PMode.ID values. In their "Ultra Light Profile", they are
setting the value for PMode.ID to "Push".
An MSH will have different
PModes for different business partners, services and actions. In the ebMS 3.0 Core
Specification, the PMode.ID value is required to be unique within an MSH and to
uniquely identify a specific PMode (see definition in D.3.5.1.). This
seems to preclude the use of a single generic value for PMode.ID
with almost any real-life deployment. The superannuation profiles rely on
UsernameToken security, which implies a bilateral agreement between sender
and recipient. As there is a bilateral agreement step anyway,
selecting a specific sub-profile could be part of that process.
The OASIS BDXR TC is looking at supporting requirements
of large and dynamic communities and might have some solutions over
time.
2) PartID
The profiles mandate a PartID property.
We commented that MIME parts already
have a unique identifier (the MIME Content ID) defined in 5.2.2.13 of ebMS 3
Core, which has a globally unique (not just in the message) identifier.
Neither ebMS3 nor AS4 say whether it is expected that a submitting application
can set the value for a MIME part, but Appendix C of the Core Specification shows an example
where an XML business document (not the the ebMS3 header) has a reference
to a named part. MIME libraries and the few ebMS3
implementations I have worked with all support this.
So instead of the PartID property the
href value could be used.
In the teleconference it was explained that this
property is used to be able to reference specific parts in error messages.
If those errors relate to business processing, then another option could
be to design the relevant XBRL business document schemas to have internal
identifiers and address the correlation only at the business
level.
3) MPCs and pull with AS4 light
client
The AS4 light client profile does not require support
for additional message partitions (other than the default one) per 2.2.1 of the
spec. The way pulling works with MPCs (see v3 Core section 3.2), an MPC is
like a FIFO queue where any client authorized to pull from an MPC has access to
messages submitted to that MPC. So if an AS4 MSH has more than one partner that gets
messages by pulling, different MPCs would be needed to make sure one partner
does not pull a message intended for another partner. (There are some
enhancements for this defined in part 2: subchannels and selective pulling, but
AS4 does not use them) Analogously to Push mode, where the sender would
post message to different HTTP addresses, with Pull the sender could assign them
to different MPCs. A profile could adopt a naming convention for
MPCs, e.g. include the partner party ID ABN or party name in the
MPC URI string value.
If we ever revisit AS4, we may want to require support
for multiple MPCs with the light client as this is a common requirement, and
support for more than one MPC is not a "heavy"
feature.
Pim
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]