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.

Status:

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 http://www.oasis-open.org/committees/legalxml-courtfiling/.

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 (http://www.oasis-open.org/committees/legalxml-courtfiling/ipr.php.

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/legalxml-courtfiling/.

Notices

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 see http://www.oasis-open.org/who/trademark.php for above guidance.

Table of Contents

1 Introduction. 5

1.1 Terminology. 5

1.2 Symbols and Abbreviations. 6

1.3 Normative References. 7

1.4 Non-Normative References. 7

2 Profile Design. 8

2.1 Service Interaction Profile Identifier 8

2.2 Transport Protocol 8

2.3 MDE Addressing. 8

2.4 Operation Addressing. 9

2.5 Request and Operation Invocation. 9

2.6 Synchronous Mode Response. 9

2.7 Asynchronous Mode Response. 9

2.8 Message/Attachment Delimiters. 9

2.9 Message Identifiers. 9

2.10 Message Non-Repudiation. 9

2.11 Message Integrity. 9

2.12 Message Confidentiality. 10

2.13 Message Authentication. 10

2.14 Message Reliability. 10

2.15 Transmission Auditing. 10

3 Schema. 11

Appendix A. (Informative) Acknowledgments. 12

Appendix B. (Informative) Revision History. 13

Appendix C. (Informative) Example Transmissions. 14

C.1 Operation Invocation. 14

C.2 Synchronous Response. 14

C.3 Asynchronous Response. 14

1 Introduction

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.

1.1 Terminology

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:

Attachment

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.

Callback message

A message transmission returned by some operations some time after the operation was invoked (asynchronously).

Document

Represents a electronic version of the paper that would have been sent as paper.

Docketing

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.

Filer

Attorneys or pro se litigants are individuals who assemble and submit Filings (data and documents).

Filing

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.

Message

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.

Message Transmission

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.

Operation signature

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.

Receiving MDE

In an ECF operation, the MDE that receives the request with the operation invocation, performs the operation and sends the response.

Sending MDE

In an ECF operation, the MDE that sends the request including the operation invocation and receives the response with the results of the operation.

Synchronous response

A message transmission returned immediately (synchronously) as the result of an operation. Every operation has a synchronous response.

1.2 Symbols and Abbreviations

The key symbols and abbreviations used in this specification include:

ECF 4.0

Electronic Court Filing 4.0

MDE

Major Design Element

OASIS

Organization for the Advancement of Structured Information Systems

URI

Uniform Resource Identifier

XML

eXtensible Markup Language

W3C

World Wide Web Consortium

WS-I

Web Services Interoperability Organization

1.3 Normative References

[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, http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/, W3C Recommendation, December 2002.

[XMLSIG] D. Eastlake., J. Reagle, D. Solo, XML-Signature Syntax and Processing, http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/, W3C Recommendation, February 2002.

1.4 Non-Normative References

2 Profile Design

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.

2.1 Service Interaction Profile Identifier

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:

urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:PortableMediaProfile-2.0

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.

2.2 Transport Protocol

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.

2.3 MDE Addressing

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.

2.4 Operation Addressing

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.

2.5 Request and Operation Invocation

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.

2.6 Synchronous Mode Response

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.

2.7 Asynchronous Mode Response

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.

2.8 Message/Attachment Delimiters

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.

2.9 Message Identifiers

The ECFOperation.xml file includes a unique sequence number and filename for each message.

2.10 Message Non-Repudiation

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.

2.11 Message Integrity

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.

2.12 Message Confidentiality

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.

2.13 Message Authentication

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.

2.14 Message Reliability

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.

2.15 Message Splitting and Assembly

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.

2.16 Transmission Auditing

This service interaction profile ensures that the receiving MDE will obtain the transmitted message in its entirety for auditing purposes.

3 Schema

A portable media compliant with this service interaction profile MUST contain an ECFOperations.xml file valid against the following schema defined in the ECF-4.0-PortableMediaProfile.xsd file:

<xsd:schema xmlns="urn:oasis:names:tc:legalxml-courtfiling:wsdl:PortableMediaProfile-4.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:portablemedia="urn:oasis:names:tc:legalxml-courtfiling:wsdl:PortableMediaProfile-4.0" xmlns:digsig="http://www.w3.org/2000/09/xmldsig#" targetNamespace="urn:oasis:names:tc:legalxml-courtfiling:wsdl:PortableMediaProfile-4.0" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>

<xsd:complexType name="ECFMessageType">

<xsd:annotation>

<xsd:documentation>An ECF 4.0 message or attachment.</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element ref="ECFMessageSequenceID"/>

<xsd:element ref="ECFMessageFileName"/>

</xsd:sequence>

</xsd:complexType>

<xsd:complexType name="ECFOperationType">

<xsd:annotation>

<xsd:documentation>The ECF 4.0 operation being invoked.</xsd:documentation>

</xsd:annotation>

<xsd:sequence>

<xsd:element ref="ECFOperationName"/>

<xsd:element ref="ECFMessage" maxOccurs="unbounded"/>

<xsd:element ref="digsig:Signature" minOccurs="0"/>

</xsd:sequence>

</xsd:complexType>

<xsd:element name="ECFOperationName">

<xsd:annotation>

<xsd:documentation>The name of the ECF 4.0 operation being invoked.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="ECFMessage" type="ECFMessageType">

<xsd:annotation>

<xsd:documentation>An ECF 4.0 message or attachment.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="ECFMessageFileName" type="xsd:string">

<xsd:annotation>

<xsd:documentation>The path to the file that contains the message contents. The path is relative to the location of the XML file indicating the operation being invoked.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="ECFMessageSequenceID" type="xsd:token">

<xsd:annotation>

<xsd:documentation>The sequence number of the ECF 4.0 message in the message transmission.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="ECFOperation" type="ECFOperationType">

<xsd:annotation>

<xsd:documentation>The ECF 4.0 operation being invoked.</xsd:documentation>

</xsd:annotation>

</xsd:element>

</xsd:schema>

Appendix A. (Informative) Acknowledgments

The following individuals were members or voting members of the committee during the development of this specification:

Participants:

Michael Alexandrou, Judicial Council of Georgia

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)

Appendix B. (Informative) Revision History

Revision	Date	Editor	Changes Made
Wd-01	2008-09-03	James Cabral	Initial version

Appendix C. (Informative) Example Transmissions

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.

C.1 Operation Invocation

The messages/operation/ folder included with this specification provides an example of a request including a ReviewFiling operation invocation.

C.2 Synchronous Response

The messages/synchronous/ folder included with this specification provides an example of a MessageReceiptMessage synchronous response.

C.3 Asynchronous Response

The messages/asynchronous/ folder included with this specification provides an example of a NotifyFilingReviewComplete asynchronous response.