OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-enotary message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [legalxml-enotary] Re: ENML v.1 Comments


Marc/All,

Please see responses below.  Let me know how to proceed with
the questions I have on open items.  Thanks.

Arshad

Arshad Noor wrote:
> Thanks for the comments, Marc.  Let me review these with the
> spec in front of me, and I'll respond to them in another e-mail;
> perhaps by tomorrow.  Thanks.
> 
> Arshad
> 
> ----- Original Message -----
> From: "Marc L. Aronson" <maronson@notary.org>
> To: "arshad noor" <arshad.noor@strongauth.com>
> Cc: "rolly chambers" <rolly.chambers@tprr.com>, "Mark Ladd" <mark.ladd@addison-one.com>
> Sent: Tuesday, November 25, 2008 9:20:25 AM (GMT-0800) America/Los_Angeles
> Subject: ENML v.1 Comments
> 
> 
> 
> 
> 
> Arshad: 
> 
> 
> 
> Please see my comments on version 1. 0, November 2, 2008: 
> 
> 
> 
> Line 41: Not to be irritating here, but you forgot to mention the District of Columbia. 
> 
	Corrected.
> 
> 
> Lines 45-46: Please be careful using “above” or “below” in this document. These sentences would be best reworded please to avoid “above.” 
> 
	This is standard text provided by OASIS as part of their
	specifications templates; I will copy Mary McRae on this
	e-mail so she can respond to your comment.  If OASIS comes
	up with text that addresses your concern, I will replace
	it.
> 
> 
> Line 172: What is “IETF RFC 2119?” You need to define this term please. 
> 
	Its referenced on lines 242-243.
> 
> 
> Lines 1998-195: Why are the words Notary Public capitalized? Mark L. and I have a pet peeve over this; it’s a long story! 
> 
	No particular reason.  I've treated the title much like I
	might any official title, such as "Peace Officer", "Mayor",
	"Sheriff", etc.  Is there a convention I ought to follow?
> 
> 
> Line 200: I have problems with the words “specified by law.” Just a few minutes ago I reviewed an acknowledgment for a Pennsylvania recorder of deeds. On a good day it was lousy! However it would have been possible to record using this non-standard form of acknowledgment. What about the many, many that do not conform to any law? 
> 
	In California, effective 1/1/08, it is specified by law:
	http://www.sos.ca.gov/business/notary/notary_ack.htm.  I
	haven't researched the other 49 states and DC, so I chose
	to be conservative on this.  However, I have changed it to
	"specified by law in some states"; is that OK?
> 
> 
> Line 208: I have a problem with the word ‘legal.” Are there illegal jurisdictions? 
> 
	Removed.
> 
> 
> Line 262: I would suggest to you that in countries outside of the United States that there is more than a “modicum of formality.” You may want to re-write so as not to insult our foreign notary brothers and sisters. 
> 
> 
	Rewritten to state: "Requiring a modicum of formality in the US
	– perhaps more than a modicum in others - it...."
> 
> Line 276: I think you need an ‘s’ at the end of the word “transaction.”? 
> 
	Corrected.
> 
> 
> Line 278: I would suggest removing the word “legally.” What do you think Rolly, is it outside of our duty here to dive in to what is or is not ‘legal?’ 
> 
	Removed the words "legally admissible".
> 
> 
> Line 279: Please add the word “and” after the semi-colon. It is common practice to do this when generating a list of bullet points and upon getting to the second to last bullet point. 
> 
	Corrected.
> 
> 
> Line 280. Replace to semi-colon with a period please. 
> 
	Corrected.
> 
> 
> Line 288: What about adding “or in combination with paper?” 
> 
	Replaced with "which can be used in conjunction with or without
	paper-based notarized documents"
> 
> 
> Line 289: Here is where I show my tech ignorance: What are we verifying here please? “…software perform the verification…” 
> 
	The software is, initially, verifying that the notary's
	signature covers the rest of the notarized document and
	that the document has not been modified since the notary
	signed it.  If there is a second signature and a second
	notarial certificate, the ENML should verify the first
	notary's signature correctly, and allow for a second
	notary's signature to verify the second signature and
	notarial certificate's content.

	I think I need to mention this somewhere in the "Background"
	section; let me think about the most appropriate place to
	put this statement.
> 
> 
> Line 306: “improvements?” What is an improvement? eNotarization can be or is different than paper notarization, but is it an improvement? By what metrics? 
> 
	Changed to "...enabling improvements in the speed of creating,
	verifying and processing eNotarized documents;".
> 
> 
> Line 319: Is the word “typing” going to come back to bite us some day? Is mentioning this one form of technology too restrictive? 
> 
	Change from "by the typing in legally-admissible text" to
	"by entering relevant text".
> 
> 
> Line 324: “It is believed…” Hoped? Some other word? I think that “believed” is too optimistic. 
> 
	Changed to "hoped".
> 
> 
> Line 342: Arshad, I’m still thinking about the statement in this line about multiple documents/notarizations; maybe I’m confused. 
> 
	Currently, a document can, indeed, be signed by multiple people
	as part of a single notarization event.  However, to the best of
	my knowledge, you cannot have multiple documents (say an income
	statement and a loan agreement) covered by a single signature of
	the document-signer, a single notarial certificate and a single
	notary's signature.

	However, ENML actually allows for this possibility.  The
	<SignedDocuments> element does actually allow for multiple
	documents - each within its own <SignedDocument> element (note
	the singular name) - that can be covered (technically) by a
	single signature of the document-signer, notarial certificate
	and notary signature.

	But, until notarial law allows for this, ENML-compliant software
	should not allow this.  That's the point I was trying to make;
	does that make sense?  Should it be reworded?
> 
> 
> Line 346: If you want to stay on my Christmas card list you’ll add to this list “notary” [experts]! 
> 
	Added. :-)
> 
> 
> Line 357: There is an extra space between “The” and “first.” 
> 
	Corrected.
> 
> 
> Line 496: It is possible that a single document, containing two signatures, to be notarized by two separate notaries public, at two separate locations (or the same location) using two forms of acknowledgment. Or am I missing a point here? 
> 
	Same comment as for line 342.
> 
> 
> Line 542: I think we are being to restrictive using the term “government issued.” Maybe the word “approved?” 
> 
	Added "Produced Approved Identification Document" as a choice.
> 
> 
> Line 554: If we remove “…as required by law…” I think the sentence still works. 
> 
	Corrected.
> 
> 
> Line 569 and previous 424: I do not know anything about XML. In line 424 the date is expressed as “ 2007-02-07 .” In line 569 the description states “ February 07, 2007 .” Even if all of this is OK, I’ve never seen anyone write the date using “07” after the word “February.” 
> 
	The format of the content in Line 424 is required; the
	explanation in LIne 569 is mine.  I've corrected it to
	say "February 7th, 2007".
> 
> 
> Line 4964: It is interesting for me to note the omission of “time-of-day.” While in the paper age this had little relevance (you would not see this on a paper notarized document), in the electronic age you can hardly avoid the time of day. In fact using the time of day, whether it be a US time zone or GMT (Zulu) time, is what a computerized system does well. The time of day is touted by vendors as part of their security/audit system. 
> 
	Corrected.  Time-of-day is now included as part of the
	<NotarizationDate> element.
> 
> 
> Line 5288: Please replace “it” with “a bond.” 
> 
	Corrected.
> 
> 
> Line 5496: Good idea Arshad. 
> 
	Thank you.
> 
> 
> Line 5678: Arshad, should the sentences starting “This is because…” and ending in line 5680, that was cut and pasted from line 5639, be exactly the same in this section about states? 
> 
	Removed the repetition.
> 
> 
> Line 6246 and 47: Arshad, no matter how far out one goes in this country (rural area), there will still be a municipal and county name. Then again I may be over my head here with XML rules or something. 
> 
	No, this is not an XML rule; just a processing rule made for
	consistency in creating ID values.  While you are correct about
	US-based locations, I didn't want to presume for international
	countries, Marc.  I know that rural places in India do not
	necessarily have municipality or county names.  They do have
	"District" names.  Nonetheless, technology should allow for a
	catch-all if no rule satisfies the condition, to avoid error
	conditions in software processing.  Hence the requirement for
	the "XX" value here.
> 
> 
> Line 6251: I have a problem with the use of the term “full name.” My full name (Marc Louis Aronson) and the name that I am commissioned (Marc L. Aronson) are different, at least in the notary world (not in a court of law; that’s a different story). 
> 
	Changed to "use the name of the Notary Public by which he/she is
	commissioned to perform his/her official duties.."
> 
> 
> Line 6468: I know people who would fight with you about this, but not me! “…relatively easy to distinguish.” 
> 
	Added "(depending on the technology used in the document)" to
	the end of the sentence.
> 
> 
> Line 6488: Arshad, with all due respect, this is hype. It has always been important that a person understand what they are signing, notarized or not, going back pretty much forever. It is not more important now just because the technology we use to create the document has changed. Why would it be? (Sorry for the lecture.) 
> 
	No need to apologize.  You are correct.  I will tone it down.
	What do you think of the following?

	"It has always been imperative that document-signers clearly
	understand what they are signing. While it is easier for
	document-signers to “see” what they are signing when it is on
	paper, signing an electronic document displayed on a computer
	screen raises potential issues about whether document-signers
	are signing what they “see”.  eNotarized documents are expected
	to usher in a new age for trusted transactions.  It is
	imperative that software clearly show document-signers what they
	are signing, and that eNotarized/eWitnessed documents hold up
	to legal scrutiny by non-technical people in courts".
> 
> 
> Line 6490: Yes, I can’t wait for the first court case. You are ever so right here. 
> 
	It is my hope to avoid this, but humans are ingenuous and
	unpredictable...
> 
> 
> Line 6491: “…accept the responsibility…” Rolly: How is this different from the paper world? 
> 
	Changed to "..accept ENML."
> 
> 
> Line 6500: I’m still not real sure why XPath has been excluded, but I’m sure that Mark L. can straighten me out. I need pretty pictures, something down at my level! 
> 
	I need to do a better job of explaining this.  The 60-day
	Public Review period for the specification will give me time
	to come up with examples and pictures.  I know Abdias Lira
	had problems with this.  As a technologist, I understand his
	frustration; but when I put on my "man-on-the-street" hat on,
	I see this as fraught with problems.  I will try to come up
	with a presentation to explain this (during the PR period).
> 
> 
> 
> And that is all I have to say about this today . I was not really sure what kind of comments you were looking for. The lines and lines of XML code do nothing for me. I hope that I have not wasted your time having you read all of this. 
> 
	This is exactly what I hoped for, Marc.  THANK YOU!  I do
	hope that those with knowledge of XML will give the spec the
	same attention you gave the non-XML parts of the document.
> 
> 
> Have a Happy Thanksgiving. 

	Thank you, and the same to you too.

Arshad


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]