Subject: Orlando follow-up

From: "Kent M. Davidson" <[email-masked]>
Date: Wed, 09 Dec 1998 17:08:24 -0500

Based on some of the feedback I heard at the Orlando meeting, here are some of the issues that came up, with some of my own issues and editorializing:

* HTML Forms
	Donald asked for someone to perhaps take on standardizing or coming up with a spec for HTML Form inputs to originate or drive a IOTP session, specifically, for entering consumer data such as name, address, etc. I would be willing to donate some time to this effort if we can come up with a scope of the problem.

* Authentication
	Someone mentioned taking a look at RFC 2284, EAP (Extensible Authentication Protocol?), for the Authentication and Authentication Selection. My cursory opinion is that reuse is better than reinvention, although, don't want to slow things down. If there is interest (KISS!) from the list I will take a look at the RFC and see if it even applies.

* Document size
	Speaking of KISS, the draft-ietf-trade-iotp-v1.0-protocol-02.txt document is 239 pages long, minus about 4-5 pages of XML intro, 10 pages of the DTD, and a handful of pages of credits and a glossary. Still, it's more than 200 pages long, and probably would take one about a day to just read through, and probably 6 months to implement. I have a concern that the complexity of the protocol will stifle its adoption, as well as limit implementation to a select few. 
	If anyone else shares these concerns, I would be willing to donate some time to break the document up into several documents for 1.0 to aid in allowing people to comprehend what IOTP is, as well as letting implementation folks digest the information in smaller chunks. Otherwise, we can perhaps do this post fact in 1.1, 1.5, or whatever the new number for 2.0 will be. (another issue brought up in the meeting)

* Taxation
	One member of the audience said that he felt that the standard would fail if the 1.0 didn't address taxes even in the most minimum way, like just being able to add a field which says this much of the total amount is taxes. 
	I think we all agree that taxes and taxation is a huge rat-hole, however, I started to look for a way to see if we could add a field or two to the XML in order to put very minimal support for taxes.
	I will admit that I am rather new to IOTP and this list, but it seems as if there is no mechanism in OTP to simply send an invoiced list of goods with prices, e.g. 

	"Ladies jacket" $245.00
	"Umbrella"	$ 45.00
To which it would be rather simple to add
	"FL State tax"	$ 12.95

	The closest thing which seems to encapsulate this information is the "Order" element, which is included in the OfferRespBlk and DeliveryReqBlk. However, the spec only details a single ShortDesc to describe the goods, and the Order element is included only ONCE.
	I would infer that this is because OTP is not meant to be a bill presentment protocol. If I am incorrect, please clarify.
	Any comments on this?

* Typos/Inconsistencies and other errors
	I have identified various typos and inconsistencies in the -02 version of the draft. I will draft a separate mail covering the issues I've found.

* XML Standards for "common" elements
	I was wondering if anyone has looked into using some form of standard DTDs already in XML for consumer/customer address and name information. I haven't been following the XML standards groups well, but perhaps someone has? The element I am referring to is found in the IOTP spec: the PostalAddress element. If so, in the interest of re-use, I think it would be wise to adopt the XML standard version of these, or at a minimum, the field names.

Thanks, and looking forward to your comments,

-Kent.

___________________________________________
Kent M. Davidson, VP of Advanced Technology
Differential, Inc.
direct (408)864-0604 
fax    (408)864-0601             
mailto:[email-masked]
http://www.differential.com

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]