OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebcore message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebcore] Groups - ebcore-au-v1.0 uploaded



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.




Groet,

Sander Fieten              FIETEN IT

e: sander@fieten-it.com
t:  +31 6 51507886

This email was sent from a mobile device.

On 04 Sep 2015, at 09:10, Pim van der Eijk <pvde@sonnenglanz.net> wrote:


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 

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]