MHonArc v2.5.0b2 -->
legalxml-courtfiling message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [legalxml-courtfiling] Cancellation of proposed ballot on OXCI options
From: "Dallas Powell" <>
To: "Electronic Court Filing Technical Committeee" <>
Date: Thu, 26 Feb 2004 23:35:46 -0700
Since OXCI is not actually the standard, and there
are some members of the committee that consider OXCI to be nothing more than
another competitor, I do not think it is appropriate to call for a vote from the
TC on OXCI specific issues. I am sure that none of us mean to, but it
seems as though it is happening.
I realize that OXCI is experiencing issues
that may affect all of the committee members, and for this reason I
participate on calls specific to OXCI but, I do not believe the committee
was established to assist OXCI, so I do not feel that OXCI specific calls should
be considered official meetings of the TC.
As for the envelope, the only reasoning that I can
see that OXCI dropped it, is because ebXML has some elements that the ECF 1.1
envelope has ( but by no means all of them), and GJXDM has some elements that
the ECF 1.1 envelope has ( but not all of them). I read the
architectural document on OXCI and could find no
other valid reasoning.
However there are several other communication
methods that are included in the current vision of Blue which do not support
ebXML, and many courts that will not be receiving GJXDM document
instances for some time. In addition, currently functioning products
cannot afford to abandon existing courts nor court customers
with communication methods already functioning, and force them to adopt a
new communications method just because OXCI does not feel there is a need for an
envelope.
It will be far easier for existing courts and
integrated partners to modify an envelope than to change communications
methods. Such a change would force the courts and integrated partners to
abandon their existing architecture and move to a new one, and this motivated by
one EFM that does not deal with current customer issues. I think this is a
bad choice.
My point with the envelope is that there are more
than technical issues that should be considered, however I will post my technical reasons why the envelope should not be
abandoned as well.
I am concerned about the statement that ....Jim
would like to receive other comments on:
-
whether Court Filing Blue should
contain a required or specified envelope (an issue discussed during the Tuesday
teleconference),
-
whether his proposal for handling
fees is adequate, and
-
the feasibility of
Allen Jensen�s
recommended way of dealing with firewall security at the interface between OXCI
and the court�s case management information system data base (an issue we did
not reach on Tuesday).
Although I am sure your intent was not to make it
sound like Jim and OXCI will decide what to do with the standard, whether to
keep the envelope or not, but it sure sounds like it when you read
it.
As for handling fees, the TC needs to
agree on the Schemas that are needed and not the architectural issues of how a
product will utilize the schemas. One schema should represent information to
allow the EFM to charge for fees, and another schema should represent how the
EFSP charges for fees and communicates the information it collected to the
EFM. Another schema should include information that is sent back to the
filer that paid the fee to identify how much was charged, against what case
number, when it was charged..... and this might be supported in both cases
whether the EFM or EFSP charges. I will the elements and definitions
in a schema format that we use for processes court processes to make the charges
after it passes through the EFM, and how we encrypt the data for protection when
we include it in the envelope.
For what its worth, I do believe that users logging
in directly to the EFM as pointed out by Alan can be a danger to a network, and
I do think that Alan's design to hide the internal EFM is feasible and
appropriate for a more secure system. I also believe that multiple EFMs
should be able to communicate to each other, but I also believe that this is an
architectural issue and not a TC issue. The API to communicate to the EFM
is what the TC must focus on for interoperability, not the architecture.
Alan's security model is an excellent architectural proposal and
could be considered for an API on the back side of the EFM rather than the front
side where an EFSP communicates.
Dallas
exist still need to maintain those communication
methods
