Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, Part 2 of 2

From: [email-masked]
Date: Wed, 5 May 1999 17:31:31 -0400

I've gone over the rest of the document and have the following suggestions:

INQUIRY:

I'm not sure why inquiry is restricted as much as it is.  Seems like the thing
to do is to describe the function it performs.  Then point out that the customer
role is probably intermittantly connected and is not required to and is unlikely
to respond to inquires even if it is connected.  And then perhaps, as guidance
for the implementation of some sort of "Inquire" UI button at the customer site,
suggest it inquire of the last role to which a message was sent or all roles.
In particular, I see no reason not to allow server to server inquires.

MISCELLANEOUS:

Section 7 first paragrah and figure: might be confusing to some readers.  First
paragraph says Trading Block has Trading Components and optionally Signature
Component but figure only shows a Signature Component as part of a Signature
Block...  Suggest that Trading Block components be labeled Trading Comp. except
one labeled Siganture Comp.  Also, might note somehow that the Certificate Comp.
is optional...

Section 7.9, OTP -> IOTP.
Section 7.10, same.

Section 7.16, first sentence, suggest inserting "if required" after
"Certificates".

Sections 7.16.1, .2, .3, &.4: suggest adding "With" to the subject titles or
perhaps even "Signature Block With".

Section 8.2.2: I'm not sure that a flat statement that a PING does not start an
IOTP aware 'application' is necessarily correct.  This could be implemented in
different ways.  In any case, it seems to be contradicated by the immediately
following sentence.  Perhaps there should just be some words about it being
intended to test connectivity and basic listening / reponse functions and need
not start a full blown IOTP application or do any deep tests, or words to that
effect.

Section 10:
     In URLs, "ftp:" should be followed by "//".
     merchant.com is a real highly active web site. Suggest occurances of it be
replaced by "example.com" which is actually resreved for this purpose.  Another
possibility is using the ".example" top level domain name which is also reserved
for use in examples.
     suggest at least one BrandLogoNetLocn per example be an "http://" URL to
show that it need not always be ftp.
     BrandIDs do not correspond to text elsewhere about Brands...
     In 10.2 example, closes of <PackagedContent ...> sometimes are missing the
"/" right after the "<" and in some cases have attributes...
     In 10.4, CyberCash is the company, which offers a number of services,
including CyberCoin.  Most references seem to be to CyberCoin.  ccash.com is yet
another different real (French language) site.  Suggest ccash.example or
cybercash.com.  (mxbankuk.com doesn't exist yet but who knows...)

TRIVIA:

Section 7.7, Content, Status, last sentence "of" -> "if"
Section 7.10, same.

Section 8.1.12, figure 33, "TPO Block only i last ..." -> "TPO Block only if
last..."

Section 8.2.1, "inquiring on transaction" -> "inquiring about a transaction"
     "component hold the" -> "component holds the"
     "contain for encapsulated" -> "contain encapsulated"

Section 9: suggest lower casing the upper case occurances of "GIF".

DTD:
     I didn't review the DTD in detail.

GLOSSARY:

Delivery Handler: suggest dropping the word "physically".  Maybe substitute
"directly"?

IOTP Transaction: "of IOTP" -> "of the IOTP"

Payment Instrument: CybeCash -> CyberCoin or CyberCash's CyberCoin

Promotional Brand:  I don't think use here and in Section 10 doesn't correspond
with text elsewhere about brands.

Transaction Type: last item of bulleted list doesn't read like it should be a
list member.

Thanks,
Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
[email-masked]   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
[email-masked]   tel: 1-914-276-2668

-----------------------------------------------------------------------
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: David Burdett <[email-masked]>
Date: Tue, 18 May 1999 02:17:13 +0100

See comments below marked with ### ...

David

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	05 May 1999 14:31
> To: 	IETF TRADE WG
> Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, Part
> 2 of 2
> 
### Agreed. Plan to change the section titled "WHICH TRADING ROLES CAN
RECEIVE INQUIRY REQUESTS" to ...

MAKING INQUIRIES OF ANOTHER TRADING ROLE
One Trading Role may make an inquiry of any other Trading Role at any point
in time. 
IOTP aware software that supports the Consumer Trading Role may not:
		*	digitally sign a response if requested, since it may
not have the capability, or
		*	respond to an Inquiry Request at all since it may
not be on-line, or may consider that the request is not reasonable since,
for example, the Request was not digitally signed.
As a guideline:
		*	the Consumer should send a Transaction Status
Inquiry Block to a Trading Role only after the following events have
occurred:
		*	to the Merchant, after sending TPO Selection Block,
		*	to the Payment Handler, after sending Payment
Request Block,
		*	to the Delivery Handler, after sending Delivery
Request Block,
		*	other Trading Roles should send a Transaction Status
Inquiry Block to the Consumer only after receiving a message from the
Consumer and before sending the final "Response" message to the Consumer
		*	there are no restrictions on non-Consumer Trading
Roles sending Inquiries to other trading roles.
##

> Block... 
## Re-worded initial paragraphs as follows:
Trading Blocks are child elements of the top level IOTP Messages that are
sent in the form of [XML] documents directly between the different Trading
Roles that are taking part in a trade.

Each Trading Blocks consist of one or more Trading Components (see section
7). ##

>  Suggest that Trading Block components be labeled Trading Comp.##Agreed##
> except
> is optional...## Also agreed ##
> 
##Agreed to both. There are still some instances of "otp" in element and
attribute names - see other email. ##

> Section 7.16, first sentence, suggest inserting "if required" after
##Agreed##

> perhaps even "Signature Block With".
## Agreed. Also added new section 7.16.5 titled "Signature Block with
Delivery Response" as it is missing. It is very similar to section 7.16.3##

> not start a full blown IOTP application or do any deep tests, or words to
## Agreed ##

>      In URLs, "ftp:" should be followed by "//".
##Done##
> possibility is using the ".example" top level domain name which is also
##Done##
> show that it need not always be ftp.
##Done##
>      BrandIDs do not correspond to text elsewhere about Brands...
##Fixed##
> "/" right after the "<" and in some cases have attributes...
##Fixed##
> cybercash.com.  (mxbankuk.com doesn't exist yet but who knows...)
## Fixed##

> Section 7.7, Content, Status, last sentence "of" -> "if"
##Both fixed##

> Section 8.1.12, figure 33, "TPO Block only i last ..." -> "TPO Block only
##Fixed##

>      "contain for encapsulated" -> "contain encapsulated"
##Fixed##

> Section 9: suggest lower casing the upper case occurances of "GIF".
##Fixed##

> Delivery Handler: suggest dropping the word "physically".  Maybe
##Agreed##

> IOTP Transaction: "of IOTP" -> "of the IOTP"
##Fixed##

> ##Fixed##
##Deleted examples##

> Transaction Type: last item of bulleted list doesn't read like it should
##Renamed Transaction Type as IOTP Transaction Type and moved to earlier in
the glossary. It now seems to make sense.##

> [email-masked]   tel: 1-914-276-2668

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************