Subject: Re: Orlando follow-up

From: Terry Allen <[email-masked]>
Date: Wed, 9 Dec 1998 16:54:31 -0800

Kent Davidson wrote in part:

| * 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. 

I agree it takes awhile.  OTOH, it's a complex problem, very wrinkly.

| 	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)

Perhaps what would be most useful would be (nonnormative) short
expositions of IOTP's world view and approaches to major architectural
issues (such as signing of content, which is rather neat and could
be reused by other specifications were it accessible to readers outside
the full draft).  

| * 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. 

This is out of scope, see next.

| 	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

Right.  IOTP wisely draws the line between payment and all that goes
before.  It is likely that some matters that IOTP allows to be negotiated
as part of payment (what payment instrument am I going to use) will in
some cases be settled in the course of shopping before you get to the
IOTP phase, but it is a Real Good Idea to allow invoices in IOTP only
as included binary content, as a sort of reference.  Other initiatives
are working on how to mark up invoices.

| 	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.

Yes, nor is it meant to be an online shopping protocol.  Think of how long
the document would be if it were ...

| * 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.

There isn't an XML standard version of this info, and in practical
use, there are several ways of handling addresses.  IOTP's is a reasonable
one; EDI has a different format (though for all I know, in practice EDI
handles addresses variously).  For the Common Business Library (CBL), which 
is a prototype of what you want, I used an EDI-like approach.  I am hoping
that Commerce Net's ECO Framework Working Group will identify appropriate
standards for such things - for addresses there may be multiple formats,
who knows.  

Specifically on IOTP's address structure, it has the great advantage of
accomodating nonordinary address information and marking up only the
parts you can expect to be in every address.

A somewhat dated version of CBL is available at Veo's web site (see sig);
I hope to get an improved version (and in an XML schema language) out 
sometime in January.

regards, Terry Allen

Terry Allen				Veo Systems, Inc.
Business Language Designer	        2440 W. El Camino Real
tallen[at]sonic.net                     Mountain View, Calif., 94040
Common Business Library - available at  http://www.veosystems.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]

---

From: Kaye Caldwell <[email-masked]>
Date: Wed, 09 Dec 1998 20:22:44 -0800

Pardon what is probably very basic question - but can someone tell me if IOTP
has provisions for delivery of additional documents to the consumer, such as
warranties, licenses, or privacy agreements?
- Kaye

===================================
Kaye Caldwell,  Policy Director
CommerceNet 

http://www.Commerce.net
E-mail: [email-masked]
Phone: (831) 479-8743    Fax: (408) 273-6345
===================================
-----------------------------------------------------------------------
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]