Jim & Jim – Here are some additional items for the ECF TC to consider both in the short-run and long-run with regard to the two specifications being used in the Springboard ECF Initiative. We don’t see any of these as “show-stoppers” that
would require us to halt work on the Initiative. In other words, we believe we have reasonable workarounds to permit the initiative to proceed.
However, I’d like to schedule some time to review them with you just to be on the safe side and ensure that we haven’t misinterpreted anything. We also want to ensure that you understand what each item means before you consider sharing
any of them with the ECF TC.
A one-hour GoToMeeting would probably do the trick, but I realize that you’re both very busy next week. How does the week of September 30 look for a virtual meeting?
Let me know if there are any dates that are unavailable and/or preferred during that week.
Alternatively, if you think the list is self-explanatory and no call is needed, let me know that as well.
Here’s the list (in raw form from the engineers). As before, we offer them as constructive suggestions for consideration:
1.
Optional Interoperability?
a.
The ECF Core Specification (Section 5.1) and the ECF WS SIP define numerous optional (May/Should) requirements for several foundational aspects of the service
interaction. As such, the specifications seem to defer core decision points to the system owners/developers, thereby diminishing the overall interoperability of the system.
b.
Example:
i. Site A decides they want to leverage the optional Message Integrity [XMLSIG] and Message Confidentiality
[XMLENC] parts of the specification to securely send/receive message data.
ii. Site B, on the other hand, builds their system with only the base requirements.
iii. Site A sends an encrypted message to Site B, but Site B is not able to handle the message due to
the confidentiality encoding [XMLENC] of the message. Therefore, the two sites, which both adhere to the specification, cannot communicate.
2.
Must and/or May?
a.
The specification documents seem to provide contradictory guidance regarding some of the normative (Must/Required) and non-normative (May/Should) requirements.
b.
Section 5.1 “Service Interaction Profile Requirements” of the ECF Core Specification indicates that a SIP “SHOULD provide”:
i. Message non-repudiation
ii. Message integrity
iii. Message confidentiality
iv. Message authentication
v. Message transmission reliability
c.
Sections 1.2.5 - 1.2.8 of the ECF WS SIP, on the other hand, seem to indicate that many of those optional features are actually
required for compliance.
i. XML Signature Syntax and Processing specification is
REQUIRED
1.
Since XML Signatures provide integrity, message authentication, and/or signer authentication, the requirements seems contrary to the previously stated optional
nature of those features.
ii. [WS-I BSP 1.0]
E0002 - Security Tokens - Security tokens MUST be specified
1.
Security tokens are used to provide enhanced security feature such as encryption, thereby seemingly contradicting the guidance in Section 5.1
d.
Sections 2.10 - 2.14 of the ECF WS SIP seem to align with Section 5.1 of the ECF Core Spec, but not with sections 1.2.5 - 1.2.8 of the ECF WS SIP mentioned above.
3.
Simplify Requirements
a.
The ECF WS SIP provides requirement detail that, at times, seems to repeat, or delve into the details of, other specifications. In order to simplify the requirement
definitions, the specification could identify requirements only at the higher level.
b.
Example:
i. WS SIP calls for the use of MTOM, but then specifies deeper level requirements such as using
[RFC2045] for the message delimiter and unique “Content-ID.
ii. Since RFC 2045 is included in the MTOM specification, the WS SIP does not need to repeat the requirement.
The supplemental detail requires the reader to dig further into the specs to confirm that MTOM indeed implements RFC 2045.
c.
The ECF WS SIP would be more straightforward and easier for the reader to read / developer to implement, if the “nested” requirements were not explicitly identified.
4.
Binary Encoding
a.
The ECF WS SIP identifies the use of MTOM for all request/response message encoding. We recommend consideration of the following aspects of the binary encoding
decision:
i. Consistency:
1.
Since MTOM is a SOAP-based solution, an alternative binary encoding/storage mechanism must be provided for any non-soap SIP. As such, the core data specification
must provide another method for encoding binary data.
ii. Performance:
1.
MTOM encoding has more overhead than text/xml encoding for simple text-based messages and even small (< 5 KB) binaries. Therefore, the composition of message
data is an important factor in determining the encoding mechanism.
b.
NIEM compliant base64 encoding, which is built into the XML specification, would provide a consistent mechanism for binary encoding and transport across all
SIPs.
5.
Substitution groups .. can we have a <choice>?
a.
Substitution groups enable message exchange systems to define data with a high degree of flexibility and extensibility. Substitution groups, however, also greatly
increase the complexity of a system.
b.
In many cases, the complexity of substitution groups far outweighs any practical, real-world benefits. As such, implementation teams (analysts, developers,
testers) must accommodate the difficulties of substitution groups without realizing the extensibility benefits.
c.
Examples: Automated schema validation becomes more difficult with substitution groups. Further, test tools, such as soapUI, do not fully support services that
use substitution groups.
d.
Since a substitution group is really just another way to write a <choice>, we recommend consideration of moving from substitution groups to choices.
6.
Error Handling
a.
Section 2.4 of the ECF WS SIP states:
i. The response to a request for an operation not supported by the court MUST be reported using the ECF
4.0 <ErrorCode> element in the core message and MAY also include a SOAPFault in the SOAP envelope.
b.
The requirement seems to have two issues:
i. First, in the event that a web service has not implemented an operation, the client will receive a
standard SOAP fault, not an application-level error from the server.
ii. Also, a service cannot generate two synchronous responses to the same request, so either a response
with the <ErrorCode> element or a SOAP fault will be sent.
=====
Scott Serich, PhD, JD
Lead Technical Architect, IJIS Institute
44983 Knoll Square, Ashburn, VA 20147-2692
703.283.3432 -- scott.serich@ijis.org --
www.ijis.org
=====