Subject: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part 1

From: [email-masked]
Date: Thu, 22 Apr 1999 18:25:11 -0400

I've done a careful review of the document through section 6 and section 13
and greater and came up with the following somewhat length list of
suggestions.  I don't think they substantially change the intended meaning
of the document but those on the list should judge that.

IMPORTANT:

"IANA Considerations" needs to be a top level section, perhaps #11.
Gathering this stuff together into 3.7.3 is good but its still unreasonable
to expect IANA to comb the document to find it.
     I'm not sure about the criteria for registration.  "IETF Consensus" is
pretty stiff and requires a vote of the IESG.  I should think someone could
register an IOTP Band or CurrCode by publishing an RFC.  Perhaps that is
what you mean for ProtocolId but it is not clear.
     Toward end so 3.7.3, change "with" to "without".

MISCELLANEOUS:

I don't understand the difference between "Objectives" and "Purpose".  I
suggest that 1.4 and 1.5 be merged and that the reference to "IOTP Business
Description" which, as far as I know, is not intended to ever become an
IETF document, be dropped.

Section 1.7 still refers to an XML Overview section 11.

Page spanning figures, like Figure 3, are really pretty messy.  It would be
better if the text could be made much more terse and this and similar
figures started high on a page so they aren't split by a page boundary.

Section 2.2: suggest "The Open Trading Protocols identify" be changed to
"IOTP identifies".
Section 2.2: says "IOTP Transactions are composed of these exchanges" but
does not list Inquiry or Ping exchange.

Starting in section 2.3 and many other places in the document, words or
phrases are prefixed and suffixed by an underscore character ("_").  This
is not any normal IETF style.  I suspect it means that the original text is
italic.  These should be suppressed or if that is impossible, a separate
pass should be done to delete them.

In Figure 9, the things which are supposed to be identical or match aren't
and don't.  Is that deliberate?

I don't think that section 3.6 Brands and Brand Selection fits very well
where it and suggest it be moved into section 10 which could be renamed
"Brands".
     Continuing on Brands, I looked around a bit in SET literature and
couldn't find anything about Dual or Promotional brands or anything about a
three component SET Brand.  Two components, "brand" and "product" I see in
the SET literature, such a "MasterCard" or "Visa:Gold".  But not A:B:C and
no case where a colon is included if there isn't anything after it.  In
other words, it's "Visa", not "Visa:", and certainly not "Visa::" as a SET
brand (re also examples in 6.6.1). Can anyone give me any references to
shed light on this?

Section 3.8.1: I don't understand why sub-pages of an HTML main page
couldn't have links back to the main page.

Section 4.1: first section reference says "0"?

Figures 10 and 11: These flow diagrams each *almost* fit on a page. If the
initial "Input IOTP Message" box could be to the side with a horizontal
arrow and the text were edited down to something a bit more terse, I think
they would, which would be quite helpful.

Section 5: Suggest this section be called "Digital Signature" or something.
Usually an IETF Security Considerations section is brief and talks about
really high level issues.  Material in 5.4 is appropriate for Security
Considerations.  A separate Security Considerations section would need to
also say something about deciding when to require signatures, even if it is
just by referring to section 5.1.4, and about depending on payment scheme
security for the safety of funds, which I didn't see anywhere.
     Section 5 seems pretty heavy on certificates and public key crypto,
especially given the originally IOTP v1.0 was going to be secret key only
and, as I recall, it was with some reluctance that public key hooks were
added.  The stuff on checking a signature, for example, talks about
checking the certificate as if there always has to be one.
     Section 5.1.4: another reason you might not need signatures is the
that the sender and receiver were on the same machine so it can check
integrity just by comparing with a saved copy.

Section 6.4.2: Need to eliminate reference to "Open Trading Protocol
Consortium" and suggest dropping whole note. I don't see any difference at
all between OkTo/OkFrom and amount.  Both could appear in human readable
form in the Order Description and in machine readable form in their
element.  Recommending that the UI display the machine readable version is
reasonable (as in 6.4.1).

ContentSoftwareId: the standard text given for this is quite length and
repeated dozens of time.  If it could be moved to the glossary or something
and a simple "see glossary" put in, it would save many pages.

As previously discussed, change ISO4217 to ISO4217A or the like.

Just before section 6.7, it says that examples exist in 6.6 when they are
in 10.

Section 6.17: references to the Richard Brown draft and probably not
appropriate.  RFCs are not supposed to refer to drafts.  About the future,
I'm not sure you need to say anything but if you do, I think it should just
say the future versions of IOTP will use industry standard XML signature
technology if it meets IOTP requirements.
     Shouldn't 6.17.1 refer to the IOTP DSIG document?  It's OK to refer to
that draft because the idea is that it and the main protocol document will
be issued as RFCs simultaneously.  Maybe the XMLDSIG reference should just
be changed to refer to the IOTP DSIG document.
     There is a reference in  6.17.1 to payment scheme specific algorithms.
Wouldn't their use be encapsulated inside the packaged contents and be in
the payment scheme modules, not an IOTP implementation itself?
     Section 6.18: similarly for certificate reference.  Should point out
that certs not needed for symmetric keying or for cases where public key
has been registered at recipient.

Section 6.19.2: For ElContIllegal, ValueTooSmall, and ValueTooLarge, I
believe it should say "content" rather than "PackagedContent".

TRIVIAL NITS:

In the Abstract and section 1, Delivery Handler is capitalized but payment
handler isn't.

It is not usual to have a section like 1.7, History, in an IETF document.
If the evolution of a protocol sheds light on its technical content, that's
one thing.  But it is not usual to have what is mostly a list of editing
versions.  Suggest it be dropped to shorten the document.

I'm not sure why there is a skip to new page before section 3.1 or 3.1.2.
Suggest dropping these to make the document more compact.  RFC style is to
have no skips to the start of a new page anywhere in the body text.

Section 3.8 example packaged content:  I don't like the "Name"s FirstMsg
and SecondMsg.  Using Msg => Message seems confusing.  Suggest FirstPiece
and SecondPiece.

Section 3.10 says "Where both types of net location are present, the
following rules apply:" and then gives three rules only the third of which
applies in the described circumstances.  Suggest moving the first two up
and combining the quoted phrase with the third.

Section 3.11.1 "treated by the recipient is an error": is -> as

Section 4: "There are a several ..." delete "a"

Section 4.4.1.2: in first sentence has -> have.

Section 4.4.2.9: in first sentence, insert "server" between "the" and
"unless".

Not sure why skip to new page before section 5.3.1 shortly before Figure 14
which overflows onto next page by just one line...

Section 5.3.1.1: numbered subsections, lettered subsubsections:  The text
at the ends of these 12 subsubsections is substantially the same.  Starting
with 3)b) sometimes the final period is omitted.  Suggest moving this text
up to the numbered section level or to before the whole two level list.

Section 5.3.1.2: ditto 5.3.1.1 except list is one level.

Section 6.1: towards the end, delete "the" from "that the should".

Section 6.2: Insert "may be" after "there" in "there only one".

Section 6.5.5: PostalCode missing from detailed attributes list.

Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".

Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the TLS
RFC to the References.

Section 6.11:  has "Plain/Text" where other similar sentences use "Plain
Text" which is probably better.  The "/" makes it look like a MIME type and
the MIME type is actually text/plain.  But I would suggest not using the
MIME type as there isn't a unique one for HTML.

Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must" ->
"Mechanism and must".

Section 6.13: Content, should be "PackagedContent" not "Delivery Note".

REFERENCES (section 14)

For DOM-HASH, can't refer to any Internet-Drafts by URL or filename.  For
HMAC, suggest refereing to RFC 2104 HMAC: Keyed-Hashing for Message
Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.

It looks pretty odd to the IETF spelled out in the RFC references.  I've
never seen that in an IETF document references section.

For SET, suggest referencing the SETco.org site, not Mastercard.  Can't
reference the Brown XMLDSIG draft in an RFC (although you can talk about it
without a URL or file name reference if necessary).

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: Wed, 28 Apr 1999 02:31:36 +0100

I'm working my way through Don's comments and came across this one where our
friends in Japan might be able to help ... I think ...

Don says ...

	"I looked around a bit in SET literature and couldn't find anything
about Dual or Promotional brands or anything about a three component SET
Brand.  Two components, "brand" and "product" I see in the SET literature,
such a "MasterCard" or "Visa:Gold".  But not A:B:C and no case where a colon
is included if there isn't anything after it.  In other words, it's "Visa",
not "Visa:", and certainly not "Visa::" as a SET brand (re also examples in
6.6.1)."

This requirement arose as a result of meeting the needs of the Japan market.
Can some people who are more familiar with this, please have a look at this
part of the spec and check it is ok please?

David

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	22 April 1999 15:25
> To: 	[email-masked]
> Subject: 	Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt, part
> 1
> 

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

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

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

---

From: David Burdett <[email-masked]>
Date: Fri, 30 Apr 1999 00:00:50 +0100

I have responded to Don's comments with comments marked with ###. I have
also recently sent out separate emails on a number of topics which perhaps
warrant more discussion.

David

### Agreed. Move section 3.7.3 to a new section 11 IANA Considerations.###
> register an IOTP Brand or CurrCode by publishing an RFC.  Perhaps that is
### Agreed. See separate email.###
>      Toward end so 3.7.3, change "with" to "without".
### Agreed

> suggest that 1.4 and 1.5 be merged 
###Agreed
> and that the reference to "IOTP Business
###Agreed

> Section 1.7 still refers to an XML Overview section 11.
###Change to refer to IANA considerations

> figures started high on a page so they aren't split by a page boundary.
### Not sure. See separate email ###

> Section 2.2: suggest "The Open Trading Protocols identify" be changed to
### Agreed. Also suggest changing Open Trading Protocol to Internet Open
Trading Protocol in sections: 1.4,1.6, 8, 12 (heading & DTD)###

> does not list Inquiry or Ping exchange.
###This is deliberate. The Inquiry and Ping exchange are not "trading
exchanges" as they are used primarily to to ensure that messages are
exchanged correctly or to determine the current status of a transaction.###

> pass should be done to delete them.
###These seem to be caused by either a non-breakable dash or "smart quotes"
in MS Word being miss-translated when the document is converted to text.
Will fix in next version.###

> and don't.  Is that deliberate?
### No. Its a mistake. They should be the same. Will be fixed.###

> where it and suggest it be moved into section 10 which could be renamed
###Agreed. A good idea.###
> brand (re also examples in 6.6.1). Can anyone give me any references to
### I think this arose as a result of a japanes requirement. See separate
email###

> couldn't have links back to the main page.
### Disagree. See separate email.###

> Section 4.1: first section reference says "0"?
###Agreed. Will fix.###

> they would, which would be quite helpful.
### See response to comments about figure 3, and separate email###

> integrity just by comparing with a saved copy.
### I suggest quite a few changes here specifically:
*	renumber section 5 (and all later sections) as section 6 and rename
as "Digital Signatures and IOTP"
*	insert a new section 5 called "Security Considerations" which is
focussed on the types of IETF security considerations Don describes above.
Specifically including: why you might want (or not want) to use signatures;
use of asymmetric and symmetric cryptography; privacy, and payment protocol
security###

> Consortium" and suggest dropping whole note. 
### Agreed ###
> I don't see any difference at all between OkTo/OkFrom and amount.  Both
> could appear in human readable
### I think the note should remain but include suggestion that the OkFrom
and OkTo dates are displayed to the consumer.###

> and a simple "see glossary" put in, it would save many pages.
### Agreed ###

> As previously discussed, change ISO4217 to ISO4217A or the like.
### Suggest change to ISO4217-A. See other email.###

> Just before section 6.7, it says that examples exist in 6.6 when they are
### Agreed. Will fix ###

> technology if it meets IOTP requirements.
### Agreed will change to refer to IOTP Dsig paper and use of standard XML
signature technology in the future###

> be changed to refer to the IOTP DSIG document.
### ALL references to XMLDSIG shall be changed to reflect IOTPDSIG
instead.###

> the payment scheme modules, not an IOTP implementation itself?
### Not necessarily. For example a Mondex purse application on a smart card
can be used to authenticate an individual using cryptography on the smart
card chip. This means that the "Algorithm" used for authenticatiojn purposes
could potentially be: SHA1, a digital signature, or a payment protocol
specific algorithm. Therefore suggest no change.###

> has been registered at recipient.
### Agreed ###

> believe it should say "content" rather than "PackagedContent".
### Agreed ###

> In the Abstract and section 1, Delivery Handler is capitalized but payment
### Agreed ###

> versions.  Suggest it be dropped to shorten the document.
### Agreed ###

> have no skips to the start of a new page anywhere in the body text.
### This was caused by keeping figure 6 together with the immediately
preceeding lines. ###

> and SecondMsg.  Using Msg => Message seems confusing.  Suggest FirstPiece
### Changed ###

> and combining the quoted phrase with the third.
### Agreed ###

> Section 3.11.1 "treated by the recipient is an error": is -> as
### Fixed ###

> Section 4: "There are a several ..." delete "a"
### Fixed ###

> Section 4.4.1.2: in first sentence has -> have.
### Agreed ###

> ### Agreed ###
### Fixed ###

> up to the numbered section level or to before the whole two level list.
### Tidied up ###

> Section 5.3.1.2: ditto 5.3.1.1 except list is one level.
### Ditto ###

> Section 6.1: towards the end, delete "the" from "that the should".
### Fixed ###

> Section 6.2: Insert "may be" after "there" in "there only one".
### Fixed ###

> Section 6.5.5: PostalCode missing from detailed attributes list.
### Fixed ###

> Just before 6.6.3 and 6.7.1: "in10" -> "in section 10".
### Fixed ###

> Suggest replacing occurrences of "SSL" with "SSL/TLS" and adding the TLS
### Agreed ###

> MIME type as there isn't a unique one for HTML.
### Agreed ###

> Section 6.12.1: DelivReqNetLocn & SecDelivReqNotLocn: "Mechanism must" ->
### Agreed ###

> Section 6.13: Content, should be "PackagedContent" not "Delivery Note".
### Agreed ###

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200