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

From: "Lewis, Tony" <[email-masked]>
Date: Wed, 28 Apr 1999 08:14:28 -0700

In SET, the BrandID is either "brand" or "brand:product".

In Japan, there are products that are co-branded. Essentially these products
are private label cards for domestic transactions with an international
brand for non-domestic transactions. The private label can be reflected in a
SET cardholder certificate as the "promotional card name" under the
international brand's hierarchy and/or the cardholder can have a certificate
issued under the private label hierarchy.

There is no provision to carry both the private label (of the Japanese
credit card company) and the international brand as part of the SET BrandID.

Tony
> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	Tuesday, April 27, 1999 6:31 PM
> To: 	Ietf Trade WG; [email-masked]
> Subject: 	RE: Comments on draft-ietf-trade-iotp-v1.0-protocol-03.txt,
> part  1
> 
> 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
> > 
> > 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]
> > 
> 
> **************************************************************************
> ********************
> 
> 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
> 
> **************************************************************************
> *******************
> -----------------------------------------------------------------------
> 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]
> 
-----------------------------------------------------------------------
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: Yoshiaki KAWATSURA <[email-masked]>
Date: Thu, 29 Apr 1999 04:52:39 +0900 (JST)

Tony,
Yes, we know about the definition of SET BrandId.

But SET/IOTP defines the IOTP BrandID as follows in order that we
can discount for each promotional brand and co-brand.

--
<Assumptions>
1. The brand identification codes (character strings) defined in SET
are used in the IOTP BrandID.

2. SET BrandID is defined as brand:[Product]. In SET, The brandID is
a brand name, which corresponds to the brand of the payment
card. Additional, The Product is a product name, which is defined the
type of product within the specific brand.

3. [Product] below is the same as the sub data of SET BrandID defined
in SET.

4. [PCN] below is a Promotional Card Name and is written in the
Certificates.

Set IOTP BrandId as follows.
SET:brand:[Product]:[PCN]

[]:Optional Field

Since SET BrandID has a colon between brand and Product, the three
colons should be able to delimit Brand, Product, and PCN.

Examples: 
SET:Visa:Gold:Walmart 
-> in this case, SET BrandID is "Visa:Gold".

SET:Visa::Visa-UC_Card
-> in this case, SET BrandID is "Visa".

SET:Visa::
-> in this case, SET BrandID is "Visa".

Thanks,

--
Yoshiaki Kawatsura Hitachi, Ltd.  

P.S. I will be in vacation from 29 Apr. to 9 Apr. This is called
golden week in Japanese. :-)

 >>>>> Wed, 28 Apr 1999 08:14:28 -0700,