[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [legalxml-courtfiling] Timestamps
I am forwarding the following message on behalf of Robert O'Brien. ( He is having difficulty with his membership rights. ) - Shane Durham LexisNexis -----Original Message----- From: Robert O'Brien [mailto:robert.obrien@cas-satj.gc.ca] Sent: Wednesday, October 12, 2005 9:10 AM To: Durham, Shane (LNG-SEA); JCabral@mtgmc.com Cc: legalxml-courtfiling@lists.oasis-open.org Subject: Re: [legalxml-courtfiling] Timestamps Shane, Jim et al Re: Authorized Timestamp To clarify further, I have talked to LexisNexis Canada about what I mentioned yesterday during the call that here at Federal Court in Canada, and they confirm that the most 'significant' date/timestamp in the envelope is the one that appears within the "<creation>" element (in Court Filing 1.0) which is a direct "child" of the root "LegalEnvelope". For example: <LegalEnvelope Version="1.0"> <MessageIdentification>LNC.2005-110-00001-00</MessageIdentification> ... <Creation> <DateTime> <Date>20051011</Date> <Time>17:19:54Z</Time> </DateTime> </Creation> <PaymentInformation> ... </LegalEnvelope> The "creation" date time stamp is assigned to an envelope only AFTER the EFSP has completely constructed the envelope and is ready to transmit the envelope to the court (all documents and attachments have been uploaded, they've gone to the online payment entity and back if required, etc). The assembled envelope is written to disk storage at the EFSP as an XML "file". They then attempt to send the envelope to the EFM. If the EFM acknowledges successful receipt of the envelope we are done. If the send does not receive a positive acknowledgment of successful processing by the EFM, the EFSP's regularly scheduled "resubmission" task will "find" the envelope in the "submissions pending" queue and will retry submission of the envelope -- every 15 minutes. The envelope contents are NEVER altered on such a "resubmission". Unless the "problem" turns out to be that the EFSP created an invalid envelope -- in such a case they might have to "fix" the envelope by hand -- but they would NOT adjust the date/time stamp. In other words, the "original" creation date/time stamp remains what was originally assigned by Filing Assembly MDE. And that is what the Court here is using as determinative of the filing date, as requested and agreed upon by the Bar. So it is not simply when the filer "authorizes" the filing, nor is it simply when the EFM or Filing Review actually receives it. Sorry for the length of this, but it is important to keep what we use in our 1.0 implementation available in version 3.0 of the standard .... >>> <Shane.Durham@lexisnexis.com> 05/10/11 5:44 PM >>> Jim, et al, Authorized Timestamp The document that I posted on 9/26/2005 contains this working definition of what I have called 'Authorized Timestamp' (call it what-you-will). The time when a user approved (released) a filing to be sent to the FilingReview process. As we discussed on the conference call, this value could be generalized and made applicable to all messages. In that case, a generalized definition might be: The time when a user or process approved (released) this message data to be transmitted to a recipient MDE. The important aspect of the definition, it that we understand this value is not synonymous with 'MessageAssembled timestamp' (n/a), 'MessageSent timestamp', or 'MessageReceived timestamp', although, in some systems, these timestamps might all be equal. FilingReviewedTimestamp In that 9/26/2005 document, I suggested that we should have a place to express the time at which a clerk decided to accept or reject a filing. In that 9/26/05 document, I proposed this draft definition of FilingReviewedTimestamp: The time when the FilingReview process (or user) decided that the filing was to be accepted or rejected (or, when it decided that the filing could not be reviewed at all) We did not discuss this proposed value in today's conference calls, but, to be honest, I think there would've been little support for this value - it is more of a 'nice to know' than a 'need to know'. But WAIT!!.... I think it might be a freebie: If we agreed to make 'Authorized Timestamp' a member of *all* of our messages... ...and also agreed to the functional definition I proposed above (or something akin to it)... ....then the FilingReview_Callback message's 'Authorized Timestamp' would represent the 'FilingReviewedTimestamp'. We would have our bases covered. How's that sound? - Shane Durham _____ From: John M. Greacen [mailto:john@greacen.net] Sent: Tuesday, October 11, 2005 11:09 AM To: Electronic Court Filing Technical Committeee Subject: [legalxml-courtfiling] Conference call continuation Friends - I just touched base with Jim Cabral. To stay on our timeline, we must resolve the remaining issues today. Consequently, I have scheduled a further conference call for 4:00 pm Eastern, 1:00 pm Pacific time this afternoon. The call information remains the same: Call in number 1-605-528-8855 Access code 2892164 We will resolve the remaining issues set forth below: 7. Whether we need a FilingAuthorized Timestamp - the time when a user approved (released) a filing to be sent to the filing review process (Shane's recommendation). 8. Whether we need a FilingReceived Timestamp - the time when the filing review MDE received (lodged) a filing in addition to the originalMessageReceipt date and time (Shane's recommendation). 9. Whether we need a FiledTimestamp - the legally effective date assigned to a filed document (Shane's recommendation). 10. Whether we need a DocketingReceived Timestamp - the time when the court record process receives a docketing (Shane's recommendation). 11. Whether we should adopt a model for person-organization relationships that is independent of the model used by GJXDM (Shane's recommendation). 12 Whether we maintain the Service MDE (Shane believes that we eliminated it). I hope that most of you will be able to participate. 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) john@greacen.net
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]