RE: eService process descriptions

Shane,

 

In answer to your P.S., yes, we now have a subcommittee 
list.  I've included the list in this reply.  I am hoping others will 
do the same.

 

In response to your points, like you, I have been 
concerned about a centralized model for e-service and the issues with 
registration in that model.  I also agree that registering as a party to a 
case that can receive filings electronically (is that secondary 
service?) is different from registering to receive service for any case 
(which isn't primary or secondary service in my 
understanding).

 

I have CCed John Greacen as well because he seemed to be 
the strongest advocate for that model at the face-to-face.  I understand 
John is out of the country but I'm hoping he at least can respond to 
emails.

Jim 
Cabral 

 

From:  
[mailto:] 
Sent: Wednesday, January 05, 
2005 1:29 PM
To: ; Cabral, James E.; 
; 
Subject: 
eService process descriptions

Dallas, et al,

(Happy new 
year)

 

I agree that there may be a 
different set of functional features between a vendor-to-vendor approach, vs. a 
vendor-to-server approach.  (Note: this conversation parallels the usual 
peer-to-peer vs client-server discussions that occur so frequently in our 
work.)

 

Let's discuss - I'll try to get the 
ball rolling...

 

The biggest functional 
distinction that comes to mind:

 

In the peer-to-peer approach that 
I have been pondering, I have successfully avoided the discussion of 
how attorneys would become registered to receive eservice (aka 'eservice 
registration' or, for this conversation, let's call it 
'registration'.)

 

In a peer-to-peer approach, the 
attorney's 'eservice component' is aware of its own attorneys' eservice 
preferences.  Conveniently, the 'registration' process becomes a 
private function between an eservice component and its users.  Each 
'eservice component', is free to manage their users service profiles and 
preferences however they see fit, and to facilitate maintenance by whatever 
means is appropriate.

 

On the other hand... 

In a client-server process, there 
exists a SINGLE centralized system, responsible for tracking everyone's 
eservice preferences.  Consequently, it must 
also define the SINGLE process by which any member of the filing 
community can create, update, or remove their eservice preferences (and, 
also,  make sure users can NOT update others' service 
preferences).  Such a 'registration' process would not 
necessarily have to be electronic (we *could* continue to side-step the 
issue)... but, more than likely, it *would* be an electronic process, and, then, 
fall in our laps to define.

 

The scary part of such a 
registration process, is that there isn't a good paper-world model for us to 
follow.  To my knowledge, there is no paper-world system, where the 
community of users agree to maintain a SINGLE eservice list for ALL members of 
the community.  And so, there are no existing paper-world rules that 
dictate HOW and WHEN a centralized eservice list would be updated.   

 

I think that many of us believe 
that the courts currently *do* manage eservice lists (eg a case's party list) - 
but, every time I dig a little deeper, it turns out not to be true.  
Clerks maintain case records - not eservice lists.  There is a 
difference.  An attorney's eservice list is often a bit broader 
and often a bit more precise than the court's case 
records.

 

And, it is at that point, where I feel 
we run into something that is outside the scope of our requirements group.  
If there is no paper-world authority to maintain a centralized eservice list, 
then I think we can't invent one in the electronic world.

 

It is certainly reasonable for this 
group to define electronic equivalents of existing (paper-world) 
processes.  It is quite a different (and much more difficult) task for us 
to invent processes (ie 'central authorities') that don't presently 
exist.  At the least, it's a red flag, eh?

 

- Shane 'peer-to-peer' 
Durham

 

PS: Is there a new workgroup list in 
which this discussion should be documented?

 

 

 ----- 
Original Message ----- 

From: Clarke, 
Tom 

To: Dallas Powell ;  ;  

Sent: Wednesday, January 05, 2005 12:27 PM

Subject: RE: [legalxml-courtfiling] eService process 
descriptions

Dallas, two 
comments:

 

I think your 
interpretation accords well with the component approach we are trying to 
take.

I don’t think you got 
Shane on your address list, so he didn’t see your email.

 

-----Original 
Message-----
From: Dallas 
Powell [mailto:] 
Sent: Wednesday, January 05, 2005 11:24 
AM
To: Clarke, Tom; ; 
Subject: Re: [legalxml-courtfiling] 
eService process descriptions

 

If from your comments your 
suggestion is to avoid the distinction between court controlled or vender 
controlled, I agree.  However, I think that the intent of the 
distinction is the different feature set needed when multiple entities are 
sanctioned as service providers vs. one entity.  Whether a single 
entity sactioned is the court, the bar, or a vendor, and what role must be 
played when the different situations take place.  We need to define 
the feature sets for both and distinguish between them.

 

 

Dallas

  

  
----- Original Message ----- 
  

  

  
From: Clarke, 
  Tom 

  

  
To:  
  ;  ; 
   
  

  

  
Sent: Tuesday, 
  January 04, 2005 4:30 PM

  

  
Subject: FW: 
  [legalxml-courtfiling] eService process descriptions

  

  
 

  
FYI.

  
 

  
-----Original 
  Message-----
From:  
  [mailto:] 
Sent: Tuesday, January 04, 2005 2:06 
  PM
To: 
Cc: Clarke, Tom
Subject: RE: [legalxml-courtfiling] 
  eService process descriptions

  
 

  
I just made 
  a quick review of these materials. I particularly like the well-illustrated 
  distinction in service processes managed by the court vs those managed by the 
  vendors.

  
 

  
The 
  overall comment I have:

  
 

  
Of those 
  electronic processes indicated as being managed by 'the 
  court'...

  
 

  
To 
  me...

  
I think 
  these could be more generally thought of as 'eservice conducted through a 
  central authority' (or centralized system).  That authority *could* 
  be the court, but could also be managed by any organization sanctioned by 
  that legal community, such as the bar.  

  
 

  
I just want 
  to point out that the options aren't necessarily 'eservice directly 
  between vendors'... and 'eservice through the court'.   
  The central authority need not necessarily be the court itself, 
  eh?

  
 

  
Thanks,

  
- 
  Shane

  
 

  
 

  

  
  

  
From: John 
  Greacen [mailto:] 
Sent: Monday, December 20, 2004 2:04 
  PM
To: Electronic Court 
  Filing Technical Committeee
Subject: [legalxml-courtfiling] eService 
  process descriptions

  
Here are the materials that I 
  presented in Las Vegas, updated to incorporate the discussions that took 
  place.  I look forward to your comments and 
suggestions.

  
 

  
John M. 
  Greacen

  
Greacen 
  Associates, LLC

  
HCR 78, 
  Box 23

  
Regina, 
  New Mexico 87046

  
505-289-2164

  
505-289-2163 
  (fax)

  
505-780-1450 
  (cell)