Ron Bowmaster, Utah Administrative Office of the Courts
John Greacen, Individual Member
Adam Angione, Courthouse News Service
Roger Winters, Administrative Office of the Courts of Washington and King County Department of Judicial Administration
James Cabral, MTG Management Consultants
This specification replaces or supercedes:
This specification is related to:
Declared XML Namespace(s):
This document defines a Service Interaction Profile, as defined in section 5 of the LegalXML Electronic Court Filing 4.0 (ECF 4.0) specification. The Portable Media Service Interaction Profile may be used to store ECF 4.0 message transmissions to portable media in the absence of an active network between the sending and receiving MDEs.
This document was last revised or approved by the LegalXML Electronic Court Filing TC on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.
Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (.
The non-normative errata page for this specification is located at
Copyright © OASIS® 2008. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The names "OASIS", are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please seefor above guidance.
This document is a Proposed Standard developed by the OASIS LegalXML Member Section’s Electronic Court Filing (ECF) Technical Committee that defines a service interaction profile for use with the ECF 4.0 specification that does not require an active network connection.
This specification is intended for use with the Electronic Court Filing 4.0 (ECF4.0) specification and defines a transmission system in which the sending Major Design Element (MDE) stores message transmissions to portable media (e.g. CD, DVD, USB drive) which is then physically transported to the receiving MDE for retrieval of the message transmissions. This specification may be used in the absence of an active network between the sending and receiving MDEs.
Two use cases are contemplated for this service interaction profile:
1. Failure of a network or communications component which makes transmission through fully electronic means impossible; and
2. Transmission of a document so large that it exceeds the maximum file size of the other ECF 4.0 service interaction profiles supported by the receiving MDE.
This service interaction profile is intended for supplementary use only. It MUST NOT be used as the sole means for transmitting electronic filing messages between a Filing Assembly MDE and a Filing Review MDE. Because it is exclusively for supplementary use, it relies on and uses many of the non-functional features of one of the court’s primary service interaction profiles. The primary service interaction profile on which this message relies is identified for each transmission.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in Error! Reference source not found..
The key terms used in this specification include:
Information transmitted between MDEs that is of an arbitrary format, and is related to the message(s) in the transmission in a manner defined in the ECF 4.0 specification. An attachment may be in XML format, non-XML text format, encoded binary format, or un-encoded binary format.
A message transmission returned by some operations some time after the operation was invoked (asynchronously).
Represents a electronic version of the paper that would have been sent as paper.
The process invoked when a court receives a pleading, order, or notice, when no errors in transmission or in presence of required content have occurred, and when the pleading, order, or notice is recorded as a part of the official record.
Attorneys or pro se litigants are individuals who assemble and submit Filings (data and documents).
Electronic document collection that has been assembled for filing on a designated court case.
Major Design Element
A logical grouping of operations representing a significant business process supported by ECF 4.0. Each MDE operation receives one or more messages, returns a synchronous response message, and optionally sends an asynchronous response message back to the original sender.
Information transmitted between MDEs that consists of a well-formed XML document that is valid against one of the defined message structure schemas in the ECF 4.0 specification. A message may be related to one or more attachments, in a manner defined in the ECF 4.0 specification.
The sending of one or more messages and associated attachments to an MDE. Each transmission must invoke or respond to an operation on the receiving MDE, as defined in the ECF 4.0 specification.
Operation (or MDE Operation)
A function provided by an MDE upon receipt of one or more messages. The function provided by the operation represents a significant step in the court filing business process. A sender invokes an operation on an MDE by transmitting a set of messages to that MDE, addressed to that operation.
A definition of the input message(s) and synchronous response message associated with an operation. Each message is given a name and a type by the operation. The type is defined by a single one of the message structures defined in the ECF 4.0 specification.
In an ECF operation, the MDE that receives the request with the operation invocation, performs the operation and sends the response.
In an ECF operation, the MDE that sends the request including the operation invocation and receives the response with the results of the operation.
A message transmission returned immediately (synchronously) as the result of an operation. Every operation has a synchronous response.
The key symbols and abbreviations used in this specification include:
Electronic Court Filing 4.0
Major Design Element
Organization for the Advancement of Structured Information Systems
Uniform Resource Identifier
eXtensible Markup Language
World Wide Web Consortium
Web Services Interoperability Organization
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
[ECF 4.0] A. Angione (editor), LegalXML Electronic Court Filing v4.0, http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/, OASIS Working Draft, August 2008.
[XMLENC] D. Eastlake, J. Reagle, XML Encryption Syntax and Processing, W3C Recommendation, December 2002.
[XMLSIG] D. Eastlake., J. Reagle, D. Solo, XML-Signature Syntax and Processing, W3C Recommendation, February 2002.
This section describes the design of the portable media service interaction profile and identifies how it satisfies the service interaction profile requirements listed in Section 5 of the [ECF 4.0] specification.
Each ECF 4.0 service interaction profile MUST be identified with a unique Uniform Resource Identifier (URI) which is used in the ECF 4.0 court policy to identify the service interaction profile(s) that a given MDE supports. The ECF 4.0 Portable Media Service Interaction Profile 1.0 will be identified by the following URI:
Because this service interaction profile is exclusively for supplementary use, it relies on and uses many of the non-functional features of one of the primary service interaction profiles identified in court policy. Therefore, with the exception of identifying the supported service interaction profiles in court policy, the primary service interaction profile identifier, NOT the portable media service interaction profile identifier, will be included in all other ECF 4.0 messages.
An ECF 4.0 message is transmitted from a sending MDE to a receiving MDE by storage on a portable media (e.g. CD, DVD, or USB drive) and physical delivery of the medium to the receiving MDE. A court supporting this service interaction profile will define in human-readable court policy which transmission media (e.g. CD-R, DVD-R) and file systems (e.g. FAT, NTFS) it supports.
A sending MDE MUST include an XML file named ECFOperation.xml on the root folder of the file system on the portable media. Therefore, there MUST be only one message transmission on a single portable media. This file MUST be XML valid against the ECF-4.0-PortableMediaMessagingProfile.xsd schema included in this specification. that identifies the receiving MDE, the ECF 4.0 operation being invoked, and the files that contain each message and attachment that is part of the operation.
The sender will be responsible for arranging for the delivery of the transmission medium from the location of the sending MDE to the location of the receiving MDE. In the case of the ReviewFiling operation, the media should be delivered to the filing counter of the receiving court, unless the court describes a different physical location for receipt of these filings in human-readable court policy.
An ECF message using this service interaction profile will use the MDE addresses otherwise used by the MDEs for purposes of ECF 4.0 messages using the primary service interaction profile on which the particular message is based.
The portable medium will include this information printed in the language of the court on the front of the transport medium, on a box or sleeve in which it is transported, or on an accompanying piece of paper:
· The primary service interaction profile on which this message relies. If the court supports only one primary service interaction profile, this information is not required.
· The name of the person or entity on whose behalf the filing is submitted.
· The short title of the case and the case number if the filing is in an existing case.
· The name of the attorney, if any, submitting the filing.
· The title of the lead document submitted for filing.
· The name, physical address, and telephone number of the person or entity to whom the asynchronous response shall be transmitted when the filing transaction is complete.
The ECFOperation.xml file MUST identify the operation being invoked. The operation MUST be either a required operation as defined in the ECF 4.0 specification or an optional operation identified as supported through court policy.
In this version of the service interaction profile, the only supported operations WILL be the ECF 4.0 ReviewFiling operation and the corresponding synchronous response. It WILL NOT support any of the ECF 4.0 query, asynchronous response, or electronic service operations or the RecordFiling operation.
A sending MDE MUST include an XML file named ECFOperation.xml on the root folder of the portable media. This file MUST be a valid instance of the ECF-4.0-PortableMediaProfile.xsd schema included in this specification which identifies the receiving MDE, the ECF 4.0 operation being invoked, and the files that contain each message and attachment that is part of the operation.
The receiving MDE MUST maintain at least one computer configured to receive ECF messages using this profile. Once the portable medium is inserted, the receiving MDE will load the ECF message as if it were submitted in a fully electronic transmission.
The receiving MDE will print the synchronous response which will be physically delivered back to the sending MDE. The delivery of the printed synchronous response may be by the same person that delivered the transportation medium to the receiving MDE.
The receiving MDE MUST deliver the asynchronous response to an operation by sending the asynchronous response electronically to the sending MDE via the primary service interaction profile as if the message had been submitted in accordance with the identified primary message profile.
The sending MDE will store each message and attachment in a message transmission in a separate file on the portable media. It is RECOMMENDED that all the files that make up a message transmission be stored in the same directory.
The ECFOperation.xml file includes a unique sequence number and filename for each message.
The ECFOperation.xml file MAY include a digital signature applied to the files that contain messages or attachments. The digital signature MUST be conformant with the [XMLSIG] specification. The algorithms defined by [XMLSIG] support non-repudiation of the signer and signing date through a digital signature created using the signer’s private key. Because the sender is the only one with access to the private key and the date is included in the signature, receivers can be reasonably assured of the signer and signing date.
The algorithms defined by [XMLSIG] support message integrity through inclusion of a public-key-based digital signature. Because the signing date and message hash are included in the signature and the entire signature is computed using the sender’s private key, the receiver can compare the hashes to verify that the message has not been altered since it left the control of the sender on the specified date.
If the Filing Review MDE supports the filing of confidential documents and the publication of the court’s public key in court policy. Messages and attachments MAY be encrypted for filing into the court according to the [XMLENC] specification. Because the Filing Review MDE is the only one with access to the court’s private key, filers can be reasonably assured that only the Filing Review MDE will be able to read the message or attachment.
This mechanism MAY be used to protect sensitive or confidential information in a filing such as the FilingPaymentMessage. However, this specification does NOT support the transmission of messages and attachments encrypted with the court’s public key to other parties in the case. Any messages and attachments transmitted to other parties MUST be either encrypted with the party’s public key or not encrypted. This specification and the ECF 4.0 specification do NOT define the exchange or publication of public keys by person or organizations other than the court.
The sending MDE shall include in the ECF message the credentials that demonstrate its identity to the receiving MDE as set forth in the ECF 4.0 specification.
Reliability will not be enforced through this service interaction profile. If a filer wishes to have a guarantee that a message transmission using this service interaction profile will be delivered to the receiving MDE within a specified period of time, or receive notification that the transmission was not so delivered, that person or organization should enter into an agreement with its employee or subcontractor effecting physical delivery of the transmission medium containing such terms.
Message splitting and assembly will not be supported through this service interaction profile. It is assumed that the portable media will be sufficient in size to support an entire message.
This service interaction profile ensures that the receiving MDE will obtain the transmitted message in its entirety for auditing purposes.
A portable media compliant with this service interaction profile MUST contain an ECFOperations.xml file valid against the following schema defined in the file:
The following individuals were members or voting members of the committee during the development of this specification:
CJ Allen, Maricopa County Clerk of Court
Adam Angione, Courthouse News Service, Inc.
Donald Bergeron, Reed Elsevier
Ron Bowmaster Utah Administrative Office of the Courts
Suzanne Bunnin, Arizona Supreme Court
James Cabral, MTG Management Consultants
Rolly Chambers, American Bar Association
Thomas Clarke, National Center for State Courts
Linda Colwell, Arizona Supreme Court
James Cusick, Wolters Kluwer
Robert DeFilippis, Individual
Christopher, Shane Durham, Reed Elsevier
Eric Eastman, Doxpop, LLC
Scott Edson, LA County Information Systems Advisory Body
Ali Farahani, LA County Information Systems Advisory Body
Robin Gibson, Secretary, Missouri OSCA
Gary Graham, Arizona Supreme Court
John Greacen, Individual
Jim Harris, National Center for State Courts
Brian Hickman, Wolters Kluwer
Hui Ji, Judicial Council of Georgia
Aaron Jones, Maricopa County
George Knecht, PCIntellect LLC
Mark Ladd, Property Records ind.
Laurence Leff, Individual
Morgan Medders, Judicial Council of Georgia
Rex McElrath, Judicial Council of Georgia
John Messing, Law-On-Line
Robert O’Brien, Ottawa Courts Administration
Gary Poindexter, Individual
Rachelle Resnick, Arizona Supreme Court
David Roth, Thomson Corporation
John Ruegg, LA County Information Systems Advisory Body
Christopher Smith, California Administrative Office of the Courts
Philip Urry, Arizona Supreme Court
Roger Winters, Washington Administrative Office of the Courts (King County)
This non-normative section provides an example transmission that demonstrates an operation invocation, a synchronous response, and an asynchronous response using this service interaction profile. Note that these examples are for illustrative purposes only.
The messages/operation/ folder included with this specification provides an example of a request including a ReviewFiling operation invocation.
The messages/synchronous/ folder included with this specification provides an example of a MessageReceiptMessage synchronous response.
The messages/asynchronous/ folder included with this specification provides an example of a NotifyFilingReviewComplete asynchronous response.