Subject: RE: Question on ECML address country code usage
From: Eastlake III Donald-LDE008 <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: 'Donald Eastlake 3rd' <[email-masked]>
Date: Wed, 28 Aug 2002 07:39:54 -0400
List-Id: <ietf-trade.lists.elistx.com>

Eric,

It's not in the Charter. It's in the ECML Requirements RFC.

Donald

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Thursday, August 22, 2002 3:25 PM
To: Donald Eastlake 3rd
Cc: [email-masked]; [email-masked]
Subject: Re: Question on ECML address country code usage

> ... existing financial protocols ...
 
I must have missed that in the charter.

You've got my objection.

Eric

Date: Tue, 27 Aug 2002 14:44:44 -0400
From: Phil Roberts <[email-masked]>
Subject: Nomcom call for volunteers
Sender: [email-masked]
To: IETF WG Participants: ;

The members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering 
to be on the nominations committee.

Date: Thu, 22 Aug 2002 15:25:07 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Question on ECML address country code usage
To: Donald Eastlake 3rd <[email-masked]>
Cc: [email-masked], [email-masked]

> ... existing financial protocols ...
 
I must have missed that in the charter.

You've got my objection.

Eric

Date: Thu, 22 Aug 2002 14:59:21 -0400 (EDT)
From: Donald Eastlake 3rd <[email-masked]>
Subject: Re: Question on ECML address country code usage
To: [email-masked]

(1) ECML is supposed to support a variety of existing financial
protocols used on existing networks. As far as I know, all of them that
need any jurisdictional information include the country code (commonly
in the form on the UN country number which is equivalent). This alone is
sufficient justification for including ISO country code, keeping in mind
that all fields in ECML are optional and can be used or not as the
participants choose.

(2) ISO 3166 is a well defined standard which anyone can consult and
will therefore interpert the same way. I.E., it is interoperable, the
major goal of IETF protocols. Poking holes in it without specifying an
interoperable replacement seems pretty insignificant to me. This reason
alone is sufficient justification to include ISO country code as an
optional jurisdiction related field.

Donald

PS: I'm about to leave for vacation returning 1 Sept. so will probably 
not be very responsive between now and then.

On Thu, 22 Aug 2002, Eric Brunner-Williams in Portland Maine wrote:

> Date: Thu, 22 Aug 2002 13:52:38 -0400
> From: Eric Brunner-Williams in Portland Maine <[email-masked]>
> To: Eastlake III Donald-LDE008 <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: Re: Question on ECML address country code usage
> 
> Donald,
> 
> You and I (and Bill) wrote the IANA considerations for the DNS, and inspite
> of your initial attachment to iso3166, there was no technical necessity in
> that BCP to cite iso3166.
> 
> What is the compelling necessity here?
> 
> Eric
> 

-- 
======================================================================
 Donald E. Eastlake 3rd                       [email-masked]
 155 Beaver Street              +1-508-634-2066(h) +1-508-851-8280(w)
 Milford, MA 01757 USA                   [email-masked]

Date: Thu, 22 Aug 2002 13:52:38 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Question on ECML address country code usage
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked], [email-masked]

Donald,

You and I (and Bill) wrote the IANA considerations for the DNS, and inspite
of your initial attachment to iso3166, there was no technical necessity in
that BCP to cite iso3166.

What is the compelling necessity here?

Eric

Content-return: allowed
Date: Thu, 22 Aug 2002 12:30:51 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: RE: Question on ECML address country code usage
To: [email-masked]

No, the United States of America is one "national" jurisdiction. It permits
a vast profusion (well over 550) of subsidiary jurisdictions (cities,
counties, states, indian areas, special districts, free-ports, gores, etc.)
within it each of which is limited to the amount of individuality that is
permitted them by the USA. Furthermore, the use of ISO3166 codes is a way of
avoid any burden on the IETF of deciding what is a country and its use is
long established in the DNS and in other protocols, IETF and non-IETF.

And, perhaps most important of all, it is well defined and interoperable.

It seems to me that the way to go is ISO3166 country codes with a
supplementary "additional jurisdictional information" field to be used when
you need to specify more than the ISO country code plus the address
information.

Donald

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Thursday, August 22, 2002 6:54 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Question on ECML address country code usage

Lauri,

There are about 550 national jurisdictions contained in, or surrounded by,
the United States. ISO 3166 (aka "country codes") provides few code points
for distinguishing code points in North America.

As a protocol design issue, using two octets to contain fewer than 300
distinct data values, and mandating failure, or implementation-specific
extension, for transactions taking place within the jurisdictions of Indian
(not India) governments (but not Pitcairn's Island or any of the other odd
bits in ISO 3166), is both untidy and an overspecification.

We aren't in the buisness of deciding what is a state.

We don't need to pay a great deal of attention to the claims of others who
are in that business. Very likely, their decisions are political, and not
technical, and of necessity, not correct.

It is a good thing that iso3166 code points aren't used in ip addrs. If they
were, even getting address allocations for Indian Country would be
difficult.

Eric

Content-return: allowed
Date: Thu, 22 Aug 2002 12:30:51 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: RE: Question on ECML address country code usage
To: [email-masked]

No, the United States of America is one "national" jurisdiction. It permits
a vast profusion (well over 550) of subsidiary jurisdictions (cities,
counties, states, indian areas, special districts, free-ports, gores, etc.)
within it each of which is limited to the amount of individuality that is
permitted them by the USA. Furthermore, the use of ISO3166 codes is a way of
avoid any burden on the IETF of deciding what is a country and its use is
long established in the DNS and in other protocols, IETF and non-IETF.

And, perhaps most important of all, it is well defined and interoperable.

It seems to me that the way to go is ISO3166 country codes with a
supplementary "additional jurisdictional information" field to be used when
you need to specify more than the ISO country code plus the address
information.

Donald

-----Original Message-----
From: Eric Brunner-Williams in Portland Maine
[mailto:[email-masked]]
Sent: Thursday, August 22, 2002 6:54 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Question on ECML address country code usage

Lauri,

There are about 550 national jurisdictions contained in, or surrounded by,
the United States. ISO 3166 (aka "country codes") provides few code points
for distinguishing code points in North America.

As a protocol design issue, using two octets to contain fewer than 300
distinct data values, and mandating failure, or implementation-specific
extension, for transactions taking place within the jurisdictions of Indian
(not India) governments (but not Pitcairn's Island or any of the other odd
bits in ISO 3166), is both untidy and an overspecification.

We aren't in the buisness of deciding what is a state.

We don't need to pay a great deal of attention to the claims of others who
are in that business. Very likely, their decisions are political, and not
technical, and of necessity, not correct.

It is a good thing that iso3166 code points aren't used in ip addrs. If they
were, even getting address allocations for Indian Country would be
difficult.

Eric

Date: Thu, 22 Aug 2002 07:40:56 -0700
From: Steve Schear <[email-masked]>
Subject: Re: Question on ECML address country code usage
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: :

At 06:53 AM 8/22/2002 -0400, you wrote:
>Lauri,
>
>There are about 550 national jurisdictions contained in, or surrounded by,
>the United States. ISO 3166 (aka "country codes") provides few code points
>for distinguishing code points in North America.
>
>As a protocol design issue, using two octets to contain fewer than 300
>distinct data values, and mandating failure, or implementation-specific
>extension, for transactions taking place within the jurisdictions of Indian
>(not India) governments (but not Pitcairn's Island or any of the other odd
>bits in ISO 3166), is both untidy and an overspecification.
>
>We aren't in the buisness of deciding what is a state.
>
>We don't need to pay a great deal of attention to the claims of others who
>are in that business. Very likely, their decisions are political, and not
>technical, and of necessity, not correct.

Going forward its also likely that private currencies, probably issued by 
corporations, and denominated by some sort of derivative will become a reality.

steve

Date: Thu, 22 Aug 2002 09:50:29 +0300
From: [email-masked]
Subject: Question on ECML address country code usage
To: [email-masked]
content-class: urn:content-classes:message

Hi alls,

I would like to know opinions on the coutnry code issue in ECML. Some=
 tiem ago there was heated discussion onthe short comings of the ISO =
country code, but is there wider need for change in this field?

Also I wonder if the services actually use the country code? It would=
 seem that as ECML is/was form fill tehcnology then services would ha=
ve to support also freetext input as countru in address queries. I am=
 aware of the usage of the selection lists (option list) for the coun=
try which usage 'quarantees' service understood spelling for country =
names, but do the services ever actually then use a code for the coun=
try? Is there need for this specific country code, are the services o=
nly storing whatever was given as country name to be used in addressi=
ng?

- Lauri Piikivi=20
--------------------------------------------------------=20
Specialist, SW Architecture=20
Nokia Mobile Software

[email-masked]=20
--------------------------------------------------------=20

Date: Thu, 22 Aug 2002 06:53:30 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Question on ECML address country code usage
To: [email-masked]
Cc: [email-masked], [email-masked]

Lauri,

There are about 550 national jurisdictions contained in, or surrounded by,
the United States. ISO 3166 (aka "country codes") provides few code points
for distinguishing code points in North America.

As a protocol design issue, using two octets to contain fewer than 300
distinct data values, and mandating failure, or implementation-specific
extension, for transactions taking place within the jurisdictions of Indian
(not India) governments (but not Pitcairn's Island or any of the other odd
bits in ISO 3166), is both untidy and an overspecification.

We aren't in the buisness of deciding what is a state.

We don't need to pay a great deal of attention to the claims of others who
are in that business. Very likely, their decisions are political, and not
technical, and of necessity, not correct.

It is a good thing that iso3166 code points aren't used in ip addrs. If they
were, even getting address allocations for Indian Country would be difficult.

Eric

Date: Thu, 22 Aug 2002 09:50:29 +0300
From: [email-masked]
Subject: Question on ECML address country code usage
To: [email-masked]
content-class: urn:content-classes:message

Hi alls,

I would like to know opinions on the coutnry code issue in ECML. Some=
 tiem ago there was heated discussion onthe short comings of the ISO =
country code, but is there wider need for change in this field?

Also I wonder if the services actually use the country code? It would=
 seem that as ECML is/was form fill tehcnology then services would ha=
ve to support also freetext input as countru in address queries. I am=
 aware of the usage of the selection lists (option list) for the coun=
try which usage 'quarantees' service understood spelling for country =
names, but do the services ever actually then use a code for the coun=
try? Is there need for this specific country code, are the services o=
nly storing whatever was given as country name to be used in addressi=
ng?

- Lauri Piikivi=20
--------------------------------------------------------=20
Specialist, SW Architecture=20
Nokia Mobile Software

[email-masked]=20
--------------------------------------------------------=20

Content-return: allowed
Date: Wed, 21 Aug 2002 16:19:27 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: RE: Comments to ECML v2 draft v4 (July 2002)
To: [email-masked]

Since there haven't been any further suggestions or comments, something
close to these suggested changes will be incorporated into the draft.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 08, 2002 4:20 AM
To: [email-masked]
Subject: Comments to ECML v2 draft v4 (july 2002)

Hi alls,

Comments on the new draft ECML v2 specification (version 4, July 2002).

I think it would be good to have in the Intoroduction a clear statement of
the two uses of ECML: consumer payment information input and
business-to-business transaction clearing. And for these two purposes state
that the consumer payment info input is most likely HTML form fill, and that
XML documents are seen as the format for business-to-business
communications. I think it is good to state the support for form fill, as
most servers will have to support it for consumers without wallet
applications in browsers.

Then specific comments to Nokias requirements. I noticed that there are
fields missing that were requested and had very little comments -- so no
objections to them as I understand. These fields are listed below in
'subject areas'.

LOYALTY CARD

Expiry date fields were proposed, following format for payment cards. It was
proposed that there be Ecom_Loyalty_Card_ExpDate_Day,
Ecom_Loyalty_Card_ExpDate_Month and Ecom_Loyalty_Card_ExpDate_Year fields.
The reason for these is that some loyalty card schemes have expiry dates,
for example flight bonus systems if one has received a higher status card.

Loyalty card number length is now 60, but I gathered from comments that 40
would suffice, as most systems use the magnetic stripe card track 2 for
this, with maximum length of 39 characters. 

USER DATA
User data had additional proposed fields, Ecom_UserData_Gender
(M)ale/(F)emale, Ecom_UserData_BirthDate_Day, Ecom_UserData_BirthDate_Month,
Ecom_UserData_BirthDate_Year and Ecom_UserData_Preferences (free text field
length 60).

DEVICE ID
Device ID length is currently 70 characters to support character
presentation of IPv6 address. This is an attempt at future-proofness,
currently we see lenth as 20 characters for presenting a 64 bit number or
toher commonf ID length of 48 bit number. So keeping in mind this MIN length
definition, a length of 20 charactes should suffice as MIN length. 

Device ID type was proposed as brand name field, no IAN or other registry is
seen as necessary for these types. 

And explanation for these Device ID fields could be as follows: Immutable
Device_ID or serial number that can be later verified and used for device
identification. As was explained in the first posting, this field is seen as
used in ticketing cases, where a user purchases e.g. a server-based movie
ticket at a web server. The device Id, for example of mobile phone serial
number etc, is given as the access token to server. Then, at the movie
theatre, the device ID can be rad from mobile phone and access can be
verified at the server. Type field explanation: Brand name of Device_Id
system or technology. As was explained, the type would be user
understandable brand name e.g. 'speedpass' instead of e.g. 'Bluetooth
address'. 

- Lauri Piikivi 
-------------------------------------------------------- 
Specialist, SW Architecture 
Nokia Mobile Software

[email-masked] 
phone: +358 7180 47045 
mobile:+358 40 559 7045 
-------------------------------------------------------- 

Content-return: allowed
Date: Wed, 21 Aug 2002 16:19:27 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: RE: Comments to ECML v2 draft v4 (July 2002)
To: [email-masked]

Since there haven't been any further suggestions or comments, something
close to these suggested changes will be incorporated into the draft.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 08, 2002 4:20 AM
To: [email-masked]
Subject: Comments to ECML v2 draft v4 (july 2002)

Hi alls,

Comments on the new draft ECML v2 specification (version 4, July 2002).

I think it would be good to have in the Intoroduction a clear statement of
the two uses of ECML: consumer payment information input and
business-to-business transaction clearing. And for these two purposes state
that the consumer payment info input is most likely HTML form fill, and that
XML documents are seen as the format for business-to-business
communications. I think it is good to state the support for form fill, as
most servers will have to support it for consumers without wallet
applications in browsers.

Then specific comments to Nokias requirements. I noticed that there are
fields missing that were requested and had very little comments -- so no
objections to them as I understand. These fields are listed below in
'subject areas'.

LOYALTY CARD

Expiry date fields were proposed, following format for payment cards. It was
proposed that there be Ecom_Loyalty_Card_ExpDate_Day,
Ecom_Loyalty_Card_ExpDate_Month and Ecom_Loyalty_Card_ExpDate_Year fields.
The reason for these is that some loyalty card schemes have expiry dates,
for example flight bonus systems if one has received a higher status card.

Loyalty card number length is now 60, but I gathered from comments that 40
would suffice, as most systems use the magnetic stripe card track 2 for
this, with maximum length of 39 characters. 

USER DATA
User data had additional proposed fields, Ecom_UserData_Gender
(M)ale/(F)emale, Ecom_UserData_BirthDate_Day, Ecom_UserData_BirthDate_Month,
Ecom_UserData_BirthDate_Year and Ecom_UserData_Preferences (free text field
length 60).

DEVICE ID
Device ID length is currently 70 characters to support character
presentation of IPv6 address. This is an attempt at future-proofness,
currently we see lenth as 20 characters for presenting a 64 bit number or
toher commonf ID length of 48 bit number. So keeping in mind this MIN length
definition, a length of 20 charactes should suffice as MIN length. 

Device ID type was proposed as brand name field, no IAN or other registry is
seen as necessary for these types. 

And explanation for these Device ID fields could be as follows: Immutable
Device_ID or serial number that can be later verified and used for device
identification. As was explained in the first posting, this field is seen as
used in ticketing cases, where a user purchases e.g. a server-based movie
ticket at a web server. The device Id, for example of mobile phone serial
number etc, is given as the access token to server. Then, at the movie
theatre, the device ID can be rad from mobile phone and access can be
verified at the server. Type field explanation: Brand name of Device_Id
system or technology. As was explained, the type would be user
understandable brand name e.g. 'speedpass' instead of e.g. 'Bluetooth
address'. 

- Lauri Piikivi 
-------------------------------------------------------- 
Specialist, SW Architecture 
Nokia Mobile Software

[email-masked] 
phone: +358 7180 47045 
mobile:+358 40 559 7045 
-------------------------------------------------------- 

Content-return: allowed
Date: Thu, 15 Aug 2002 17:07:31 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: RE: Unique identifier of the Voucher Component
To: 'Ko Fujimura' <[email-masked]>
Cc: [email-masked], [email-masked], Masayuki TERADA <[email-masked]>

Ko,

Yes, since there have been no comments opposing your view and some support
for it, we won't add an ID attribute in the Voucher Component.

I agree that adding some text on how to generate a unique identifier is a
good idea.

Thanks,
Donald

-----Original Message-----
From: Ko Fujimura [mailto:[email-masked]]
Sent: Thursday, August 15, 2002 6:35 AM
To: Donald Eastlake 3rd
Cc: [email-masked]; [email-masked]; Masayuki TERADA; Ko
Fujimura
Subject: Re: Unique identifier of the Voucher Component

Donald,

I'm sorry for not proposing the resolution for the issue on 
ID attribute of XML Voucher for a long time:

http://lists.elistx.com/archives/ietf-trade/200206/msg00021.html

After rethinking this issue, I can't see the requirements on 
having the ID attribute WITHIN a Voucher Component although the 
ID generation rule itself might be useful.

So, I would like propose not to introduce the ID attribute, i.e.,
keep the current spec as it is.

Alternately, it may be a good idea to add some description on 
how to generate the identifier of Voucher Component in the VTS-API 
specification (5.8.1 getIdentifier). How do you think?

Thank you

Ko

Date: Thu, 15 Aug 2002 09:12:39 -0700
From: [email-masked]
Subject: Corrected: RFC 3354 on Internet Open Trading Protocol Version 2 Requirements
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked], [email-masked]

--Boundary_(ID_g1jNWUy4OSRMC7uvgcGLEQ)
Content-type: TEXT/PLAIN

A new Request for Comments is now available in online RFC libraries.

        RFC 3354

        Title:	    Internet Open Trading Protocol Version 2
                    Requirements 
        Author(s):  D. Eastlake, III
        Status:	    Informational
	Date:       August 2002
        Mailbox:    [email-masked]
        Pages:      6
        Characters: 9671
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-trade-iotp2-req-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3354.txt

This document gives requirements for the Internet Open Trading
Protocol (IOTP) Version 2 by describing design principles and scope
and dividing features into those which will, may, or will not be
included.

Version 2 of the IOTP will extend the interoperable framework for
Internet commerce capabilities of Version 1 while replacing the XML
messaging and digital signature part of IOTP v1 with standards based
mechanisms.

This document is a product of the Open Trading Protocol Working Group
of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--Boundary_(ID_g1jNWUy4OSRMC7uvgcGLEQ)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_TfdzcJsks/a5fyvQoSzy3Q)"

--Boundary_(ID_TfdzcJsks/a5fyvQoSzy3Q)
Content-type: Message/External-body; server="[email-masked]";
 access-type=mail-server

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3354

--Boundary_(ID_TfdzcJsks/a5fyvQoSzy3Q)
Content-type: Message/External-body; directory=in-notes; access-type=anon-ftp;
 site=ftp.isi.edu; name=rfc3354.txt

Content-Type: text/plain
Content-ID: <[email-masked]>

--Boundary_(ID_TfdzcJsks/a5fyvQoSzy3Q)--

--Boundary_(ID_g1jNWUy4OSRMC7uvgcGLEQ)--

Date: Thu, 15 Aug 2002 19:34:31 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: Unique identifier of the Voucher Component
To: Donald Eastlake 3rd <[email-masked]>
Cc: [email-masked], [email-masked], Masayuki TERADA <[email-masked]>, Ko Fujimura <[email-masked]>

Donald,

I'm sorry for not proposing the resolution for the issue on 
ID attribute of XML Voucher for a long time:

http://lists.elistx.com/archives/ietf-trade/200206/msg00021.html

After rethinking this issue, I can't see the requirements on 
having the ID attribute WITHIN a Voucher Component although the 
ID generation rule itself might be useful.

So, I would like propose not to introduce the ID attribute, i.e.,
keep the current spec as it is.

Alternately, it may be a good idea to add some description on 
how to generate the identifier of Voucher Component in the VTS-API 
specification (5.8.1 getIdentifier). How do you think?

Thank you

Ko

Date: Wed, 14 Aug 2002 11:38:29 -0700
From: [email-masked]
Subject: RFC 3354 on Internet Open Trading Protocol Version 2 Requirements
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked], [email-masked]

--Boundary_(ID_gVe+c+oIS1rYAed4M0YIYg)
Content-type: TEXT/PLAIN

A new Request for Comments is now available in online RFC libraries.

        RFC 3354

        Title:	    Internet Open Trading Protocol Version 2
                    Requirements 
        Author(s):  D. Eastlake, III
        Status:	    Informational
	Date:       August 2002
        Mailbox:    [email-masked]
        Pages:      6
        Characters: 9671
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-trade-iotp2-rep-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3354.txt

This document gives requirements for the Internet Open Trading
Protocol (IOTP) Version 2 by describing design principles and scope
and dividing features into those which will, may, or will not be
included.

Version 2 of the IOTP will extend the interoperable framework for
Internet commerce capabilities of Version 1 while replacing the XML
messaging and digital signature part of IOTP v1 with standards based
mechanisms.

This document is a product of the Open Trading Protocol Working Group
of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--Boundary_(ID_gVe+c+oIS1rYAed4M0YIYg)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_hE7KLb5RLKrFVToeDo16lA)"

--Boundary_(ID_hE7KLb5RLKrFVToeDo16lA)
Content-type: Message/External-body; server="[email-masked]";
 access-type=mail-server

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3354

--Boundary_(ID_hE7KLb5RLKrFVToeDo16lA)
Content-type: Message/External-body; directory=in-notes; access-type=anon-ftp;
 site=ftp.isi.edu; name=rfc3354.txt

Content-Type: text/plain
Content-ID: <[email-masked]>

--Boundary_(ID_hE7KLb5RLKrFVToeDo16lA)--

--Boundary_(ID_gVe+c+oIS1rYAed4M0YIYg)--

Date: Thu, 08 Aug 2002 11:20:10 +0300
From: [email-masked]
Subject: Comments to ECML v2 draft v4 (july 2002)
To: [email-masked]
content-class: urn:content-classes:message

Hi alls,

Comments on the new draft ECML v2 specification (version 4, July 2002=
).

I think it would be good to have in the Intoroduction a clear stateme=
nt of the two uses of ECML: consumer payment information input and bu=
siness-to-business transaction clearing. And for these two purposes s=
tate that the consumer payment info input is most likely HTML form fi=
ll, and that XML documents are seen as the format for business-to-bus=
iness communications. I think it is good to state the support for for=
m fill, as most servers will have to support it for consumers without=
 wallet applications in browsers.

Then specific comments to Nokias requirements. I noticed that there a=
re fields missing that were requested and had very little comments --=
 so no objections to them as I understand. These fields are listed be=
low in 'subject areas'.

LOYALTY CARD

Expiry date fields were proposed, following format for payment cards.=
 It was proposed that there be Ecom_Loyalty_Card_ExpDate_Day, Ecom_Lo=
yalty_Card_ExpDate_Month and Ecom_Loyalty_Card_ExpDate_Year fields. T=
he reason for these is that some loyalty card schemes have expiry dat=
es, for example flight bonus systems if one has received a higher sta=
tus card.

Loyalty card number length is now 60, but I gathered from comments th=
at 40 would suffice, as most systems use the magnetic stripe card tra=
ck 2 for this, with maximum length of 39 characters.=20

USER DATA
User data had additional proposed fields, Ecom_UserData_Gender (M)ale=
/(F)emale, Ecom_UserData_BirthDate_Day, Ecom_UserData_BirthDate_Month=
, Ecom_UserData_BirthDate_Year and Ecom_UserData_Preferences (free te=
xt field length 60).

DEVICE ID
Device ID length is currently 70 characters to support character pres=
entation of IPv6 address. This is an attempt at future-proofness, cur=
rently we see lenth as 20 characters for presenting a 64 bit number o=
r toher commonf ID length of 48 bit number. So keeping in mind this M=
IN length definition, a length of 20 charactes should suffice as MIN =
length.=20

Device ID type was proposed as brand name field, no IAN or other regi=
stry is seen as necessary for these types.=20

And explanation for these Device ID fields could be as follows: Immut=
able Device_ID or serial number that can be later verified and used f=
or device identification. As was explained in the first posting, this=
 field is seen as used in ticketing cases, where a user purchases e.g=
. a server-based movie ticket at a web server. The device Id, for exa=
mple of mobile phone serial number etc, is given as the access token =
to server. Then, at the movie theatre, the device ID can be rad from =
mobile phone and access can be verified at the server. Type field exp=
lanation: Brand name of Device_Id system or technology. As was explai=
ned, the type would be user understandable brand name e.g. 'speedpass=
' instead of e.g. 'Bluetooth address'.=20

- Lauri Piikivi=20
--------------------------------------------------------=20
Specialist, SW Architecture=20
Nokia Mobile Software

[email-masked]=20
phone: +358 7180 47045=20
mobile:+358 40 559 7045=20
--------------------------------------------------------=20

Date: Thu, 08 Aug 2002 11:20:10 +0300
From: [email-masked]
Subject: Comments to ECML v2 draft v4 (july 2002)
To: [email-masked]
content-class: urn:content-classes:message

Hi alls,

Comments on the new draft ECML v2 specification (version 4, July 2002=
).

I think it would be good to have in the Intoroduction a clear stateme=
nt of the two uses of ECML: consumer payment information input and bu=
siness-to-business transaction clearing. And for these two purposes s=
tate that the consumer payment info input is most likely HTML form fi=
ll, and that XML documents are seen as the format for business-to-bus=
iness communications. I think it is good to state the support for for=
m fill, as most servers will have to support it for consumers without=
 wallet applications in browsers.

Then specific comments to Nokias requirements. I noticed that there a=
re fields missing that were requested and had very little comments --=
 so no objections to them as I understand. These fields are listed be=
low in 'subject areas'.

LOYALTY CARD

Expiry date fields were proposed, following format for payment cards.=
 It was proposed that there be Ecom_Loyalty_Card_ExpDate_Day, Ecom_Lo=
yalty_Card_ExpDate_Month and Ecom_Loyalty_Card_ExpDate_Year fields. T=
he reason for these is that some loyalty card schemes have expiry dat=
es, for example flight bonus systems if one has received a higher sta=
tus card.

Loyalty card number length is now 60, but I gathered from comments th=
at 40 would suffice, as most systems use the magnetic stripe card tra=
ck 2 for this, with maximum length of 39 characters.=20

USER DATA
User data had additional proposed fields, Ecom_UserData_Gender (M)ale=
/(F)emale, Ecom_UserData_BirthDate_Day, Ecom_UserData_BirthDate_Month=
, Ecom_UserData_BirthDate_Year and Ecom_UserData_Preferences (free te=
xt field length 60).

DEVICE ID
Device ID length is currently 70 characters to support character pres=
entation of IPv6 address. This is an attempt at future-proofness, cur=
rently we see lenth as 20 characters for presenting a 64 bit number o=
r toher commonf ID length of 48 bit number. So keeping in mind this M=
IN length definition, a length of 20 charactes should suffice as MIN =
length.=20

Device ID type was proposed as brand name field, no IAN or other regi=
stry is seen as necessary for these types.=20

And explanation for these Device ID fields could be as follows: Immut=
able Device_ID or serial number that can be later verified and used f=
or device identification. As was explained in the first posting, this=
 field is seen as used in ticketing cases, where a user purchases e.g=
. a server-based movie ticket at a web server. The device Id, for exa=
mple of mobile phone serial number etc, is given as the access token =
to server. Then, at the movie theatre, the device ID can be rad from =
mobile phone and access can be verified at the server. Type field exp=
lanation: Brand name of Device_Id system or technology. As was explai=
ned, the type would be user understandable brand name e.g. 'speedpass=
' instead of e.g. 'Bluetooth address'.=20

- Lauri Piikivi=20
--------------------------------------------------------=20
Specialist, SW Architecture=20
Nokia Mobile Software

[email-masked]=20
phone: +358 7180 47045=20
mobile:+358 40 559 7045=20
--------------------------------------------------------=20

Content-return: allowed
Date: Mon, 05 Aug 2002 14:42:12 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: Use of Ecom_SchemaVersion in ECML
To: "[email-masked]'" <[email-masked]>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_NgX2cJeCw9ymcVKEhCG7Vw)
Content-type: text/plain; charset=iso-8859-1

A question as arisen about Ecom_SchemaVersion, in particular as to whether
it is intended for merchant to client or client to merchant communication.

In ECML v1, this sort of thing is a bit messy. It was permitted for the
merchant to communicate to the client by putting a value in a field. This
might be just to tell the client something or to provide a default value to
be returned to the merchant if not changed by the client. I don't think
there were any cases of serious conflict between these two uses.

In ECML v2, there is the Mode attribute to clarify this. If it is set to
Assert, then you know the field value is being sent to recipient. If it is
set to Query, then you know the recipient is being asked to insert a value
and any value provided to the recipient is a default.

Getting back to the Ecom_SchemaVersion field, these general considerations
don't seem to clarify it much.  I think if a value is provided from the
merchant, it means the level of answer the merchant is expecting. In v1, the
client is expected to change it to the level supported by the client. In v2,
this is only true if the Mode is absent or Query.

Any comments?

Donald

Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax)
Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA

--Boundary_(ID_NgX2cJeCw9ymcVKEhCG7Vw)
Content-type: application/octet-stream; name="Eastlake Donald-LDE008.vcf"
Content-transfer-encoding: BASE64
Content-disposition: attachment; filename="Eastlake Donald-LDE008.vcf"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkVhc3RsYWtlO0RvbmFsZA0KRk46
RWFzdGxha2UgRG9uYWxkLUxERTAwOA0KTk9URTpNQTA3IC0NCkFEUjtXT1JLOjtN
YW5zZmllbGQNCkxBQkVMO1dPUks6TWFuc2ZpZWxkDQpFTUFJTDtQUkVGO0lOVEVS
TkVUOkRvbmFsZC5FYXN0bGFrZUBtb3Rvcm9sYS5jb20NClJFVjoyMDAwMDQyN1Qx
NDMzMDlaDQpFTkQ6VkNBUkQNCg==

--Boundary_(ID_NgX2cJeCw9ymcVKEhCG7Vw)--

Content-return: allowed
Date: Mon, 05 Aug 2002 14:42:12 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: Use of Ecom_SchemaVersion in ECML
To: "[email-masked]'" <[email-masked]>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_xIxotS+XLa+oWda6VaHi2A)
Content-type: text/plain; charset=iso-8859-1

A question as arisen about Ecom_SchemaVersion, in particular as to whether
it is intended for merchant to client or client to merchant communication.

In ECML v1, this sort of thing is a bit messy. It was permitted for the
merchant to communicate to the client by putting a value in a field. This
might be just to tell the client something or to provide a default value to
be returned to the merchant if not changed by the client. I don't think
there were any cases of serious conflict between these two uses.

In ECML v2, there is the Mode attribute to clarify this. If it is set to
Assert, then you know the field value is being sent to recipient. If it is
set to Query, then you know the recipient is being asked to insert a value
and any value provided to the recipient is a default.

Getting back to the Ecom_SchemaVersion field, these general considerations
don't seem to clarify it much.  I think if a value is provided from the
merchant, it means the level of answer the merchant is expecting. In v1, the
client is expected to change it to the level supported by the client. In v2,
this is only true if the Mode is absent or Query.

Any comments?

Donald

Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax)
Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA

--Boundary_(ID_xIxotS+XLa+oWda6VaHi2A)
Content-type: application/octet-stream; name="Eastlake Donald-LDE008.vcf"
Content-transfer-encoding: BASE64
Content-disposition: attachment; filename="Eastlake Donald-LDE008.vcf"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkVhc3RsYWtlO0RvbmFsZA0KRk46
RWFzdGxha2UgRG9uYWxkLUxERTAwOA0KTk9URTpNQTA3IC0NCkFEUjtXT1JLOjtN
YW5zZmllbGQNCkxBQkVMO1dPUks6TWFuc2ZpZWxkDQpFTUFJTDtQUkVGO0lOVEVS
TkVUOkRvbmFsZC5FYXN0bGFrZUBtb3Rvcm9sYS5jb20NClJFVjoyMDAwMDQyN1Qx
NDMzMDlaDQpFTkQ6VkNBUkQNCg==

--Boundary_(ID_xIxotS+XLa+oWda6VaHi2A)--