|
Interesting suggestion, I'll think this over. But even if the
document remains a single document, someone could define a new
profile that adds or updates something (a new subtype of
UpdateRequest, or a new Protocol Binding), and define
conformance in relation to the original document (or documents)
with the updates applied and having precedence over the updated.
On 09/05/2015 12:05 PM, Sander Fieten wrote:
Hi Pim,
I am still working on my review. I do
already have one suggestion however. I think it might be useful
to split the current document into two or even three separate
specs. One describing the AU framework, maybe specific ones for
bindings to transport protocols and another one for the
certificate update. I think this will create a more flexible
framework. If there is requirement for update of another part of
an agreement this could more easily be specified in a new
profile.
Hi Ernst Jan,
Thanks for the feedback. As for your comments at the end of
section 3, there is a distinction between "what changes"
(e.g. a certificate) and "what needs to change" as a result
of the change. The answer to the second question is
implementation-dependent, e.g. an update for ebMS2 may
require a change to (and reload of) a CPA if the party uses
CPA, but there are ebMS2 products that don't use CPA and/or
that have a different way of storing certificate
configuration. This is up to the receiver, the sender
shouldn't need to be aware. I will try to clarify this.
You are right that there are other types of configuration
updates, such as the URL of the messaging server or IP
addresses to be configured in firewalls being the common
ones (at least in my experience). The schema extensibility
makes this quite easy, and who knows a future update of the
specification could standardize these updates. As the
immediate need is for certificate updates, the idea was to
focus on those first.
As for using AU for CPA updates, this could work for simple
changes, and if both parties are known to use CPA. But
CPPA3 greatly simplifies CPA formation from CPPs, so the
alternative could be to just re-merge with an updated CPP
and form a new CPA, and define a similar message-based
protocol for requesting a CPA. E-Health in Norway
(represented on this TC) have been using this concept in
production, with ebMS2/CPPA2, for over a decade, and can
provide input to such a protocol.
I will provide an updated version in the next few days
incorporating any comments received until then. And if
there are no objections, engage with TC Admin a few days
later to move to CSD/PR ballot.
Kind Regards,
Pim
On 09/03/2015 10:46 AM, Ernst Jan van Nigtevecht wrote:
Dear members of the ebCore mailinglist,
Please find attached some feedback and comments on the Agreement Update
specification.
With kind regards
Ernst Jan van Nigtevecht
Pim van der Eijk wrote:
/Submitter's message/
Specification:
- New content covering draft CPPA 3.0.
- Editorial clean-up.
- Error codes and descriptions.
- Acknowledgments.
Schema:
- Some typos corrected.
- HTML documentation regenerated.
-- Mr. Pim van der Eijk
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|