[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Opinions on Untargeted Issues
241 CPPID uniqueness. Suggest targeting version 2.0. A Proposed solution: The cppid attribute values must be globally unique. The version attribute value must change whenever anything is added to the CPP. The cppid must change if anything already present is deleted or modified. Open issue: Registry has a urn for uuids. Should we show this option by an example? Should we say we recommend a urn:uuid:vcxzfd109qj0retc format? Status: Open. Needs consensus on some solution. Needs someone to write and send to Tony ASAP. 242 Asynchronous interactions using the HTTP binding "After the sender sends an asynchronous request to the receiver, the latter is supposed to return a 200 OK status code. How long must the sender wait for this status code?" Proposed version: 3.0 We should, IMO, not get involved in trying to define a recommended value for this wait. The TCP default is, in effect, unbounded wait. Web servers often have a timeout and reply with a 5xx to deal with a hang in a servlet or equivalent module. "Should we leave this as a local configuration parameter or do we need to specify a mutually agreed timeout in the CPA?" Local configuration parameter... but, If the question is, "Should we encourage parties to agree on some value for this timeout by adding an attribute on the MessagingCharacteristicsElement?" I think we could save this and target the issue for 3.0. 243 Arvola: Is there is a real need for section 8.2 (schemaLocation Attribute) in the CPP/A spec. On the other hand, if we remove this section, subsequent section numbers will change and cause havoc to the hard coded section references that have not been turned into symbolic references. In particular, I think the CPA composition appendix have not been converted to use symbolic section references Target version 2.0. I believe all these issues have now had resolutions. Recommend status of resolved. 244 PackageID for MSH level messages Proposed solution in current draft. Recommend status of resolved. 245 Usage of ApplicationCertificateRef and ApplicationCertificateRef Description "Is this certificateRef limited to the use of application level digital signatures? What about encryption? If both are used, the KeyInfo could need to contain two (or more) certificates. Is this OK? Certificates (if v3) do have KeyUsage fields. "I think sections 8.5.6 and 8.5.7 may need some beefing up." Needs more specific direction on what more to add. Suggest that we target anything more for 3.0.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC