Subject: Re: Unique identifier of the Voucher Component
From: Ian Grigg <[email-masked]>
To: Ko Fujimura <[email-masked]>
Cc: Donald Eastlake 3rd <[email-masked]>, [email-masked]
Date: Wed, 19 Jun 2002 10:24:00 -0400
List-Id: <ietf-trade.lists.elistx.com>

Hi all,

(I think I've been blind CC'd by Mr Fujimura, apologies
for leaping in here.)

Ko Fujimura wrote:

> > I suggest that in the next version of this an ID attribute should be
> > added to voucher. To assure uniqueness, we might also recommend that the
> > ID value be the based64 of a hash of the Exclusive Canonicalization
> > <http://www.w3.org/TR/xml-exc-c14n> of the voucher element with the ID
> > attribute dropped out. That is, something like
> >
> > Base64 ( SHA1 ( ExclusiveCanonicalization (
> >            XPath ( voucher,
> >                    ( //. |
> >                      //namespace::* |
> >                      /@[ localname() != Id ] |
> >                      /descendant::node()/@
> >                    ) )
> > )))

I would fully approve of using the SHA1 of the "voucher"
as the unique identifier.  We've been using this with
Ricardian Contracts since 1995, and it has worked well.

In fact, it is a critical piece of the architecture,
allowing for a reduction of administration over all
other payment schemes that exist.  It literally
eliminates the need to control the issuance of new
contracts ("vouchers" in your system), which massively
expands the applicability.  It also enforces agreement
on the text of the contract with very little adminstration.

(It is critical to get the canonicalisation correct, of
course.  But you seem to already have that under control.)

> Thank you for inputting a good idea. Actually, I received a comment
> below about 3 month ago regarding this issue:
> 
> > > > We are currently working on a project where tickets are
> > > > stored in a central system and
> > > > can be sold by retailers using a POS terminal in a shop. The
> > > > terminal communicates
> > > > via GSM (SMS/internet/direct) to the central system.
> ... (snip)
> > > > So here they are:
> > > >
> > > > 1. We need some unique number for every type of ticket to
> > > >    identify the ticket.
> > > >    If the terminal ask for a certain type of ticket we want
> > > >    to search for this ticket-type in the central database.
> > > >    I was looking for adding this number in the 'issuer'
> > > >    part, but I think there needs
> > > >    to be some global authorization organization for ticket
> > > >    identifiers. What are you're thoughts about this?
> 
> I have been reluctant to add ID attribute to <Voucher> because
> I think an implementation may use the hash value of the whole
> Voucher Component as the unique identifier of the <Voucher>.
> In this case, I thought it impossible to define the hash value
> as the value of ID attribute within the <Voucher>, which is the
> subject to calculate the hash value. But, Donald's idea enables
> us not to include the hash in itself. So, I agree to add ID
> attribute to the <Voucher>. Any opinions?

I wonder why you would want to do that?  Thinking in
normalisation terms (c.f. Codd) this is a duplication
of information.  Thus, you would have to think of the
case for the wrong identifier being in place.  This
would be a bug, and would introduce complications into
the architecture.

I thought this morning about how I would add the digest
to the Ricardian Contract and realised that it would
break the notion of the contract.  Part of the security
of the system resides on the ability for all parties to
agree on the text, via the compression into the digest.
By offering a short cut, this would introduce a security
flaw into the Ricardo architecture which would impact on
a lot of the governance.

Now, maybe your vouchers are not necessarily considered
to be contractually strong, in the Ricardian sense, so
maybe you don't face the same security concerns.  And,
maybe there is a reason for caching the number.  But I
don't see it.

In practice, digest cycles are cheap.  I would suggest
that you want to look carefully at calculating the digest
on the fly rather than storing it in the voucher.  And,
if it were cached, consider very carefully what that
means, and why!

-- 
iang

Date: Wed, 19 Jun 2002 13:45:36 +0900
From: Ko Fujimura <[email-masked]>
Subject: Unique identifier of the Voucher Component
To: Donald Eastlake 3rd <[email-masked]>
Cc: [email-masked], Ko Fujimura <[email-masked]>

Hello Donald and all,

Donald Eastlake 3rd wrote:
> 
> Hi,
> 
> I suggest that in the next version of this an ID attribute should be
> added to voucher. To assure uniqueness, we might also recommend that the
> ID value be the based64 of a hash of the Exclusive Canonicalization
> <http://www.w3.org/TR/xml-exc-c14n> of the voucher element with the ID
> attribute dropped out. That is, something like
> 
> Base64 ( SHA1 ( ExclusiveCanonicalization (
>            XPath ( voucher,
>                    ( //. |
>                      //namespace::* |
>                      /@[ localname() != Id ] |
>                      /descendant::node()/@
>                    ) )
> )))

Thank you for inputting a good idea. Actually, I received a comment 
below about 3 month ago regarding this issue:

> > > We are currently working on a project where tickets are
> > > stored in a central system and
> > > can be sold by retailers using a POS terminal in a shop. The
> > > terminal communicates
> > > via GSM (SMS/internet/direct) to the central system.
... (snip)
> > > So here they are:
> > >
> > > 1. We need some unique number for every type of ticket to
> > >    identify the ticket.
> > >    If the terminal ask for a certain type of ticket we want
> > >    to search for this ticket-type in the central database.
> > >    I was looking for adding this number in the 'issuer'
> > >    part, but I think there needs
> > >    to be some global authorization organization for ticket
> > >    identifiers. What are you're thoughts about this?

I have been reluctant to add ID attribute to <Voucher> because
I think an implementation may use the hash value of the whole
Voucher Component as the unique identifier of the <Voucher>.
In this case, I thought it impossible to define the hash value 
as the value of ID attribute within the <Voucher>, which is the 
subject to calculate the hash value. But, Donald's idea enables 
us not to include the hash in itself. So, I agree to add ID
attribute to the <Voucher>. Any opinions?

Best regards,

Ko

Date: Tue, 18 Jun 2002 08:58:56 -0400 (EDT)
From: Donald Eastlake 3rd <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-trade-voucher-lang-03.txt
To: [email-masked]
Cc: [email-masked]

Hi,

I suggest that in the next version of this an ID attribute should be
added to voucher. To assure uniqueness, we might also recommend that the
ID value be the based64 of a hash of the Exclusive Canonicalization
<http://www.w3.org/TR/xml-exc-c14n> of the voucher element with the ID
attribute dropped out. That is, something like

Base64 ( SHA1 ( ExclusiveCanonicalization (
           XPath ( voucher,
	           ( //. |
                     //namespace::* |
                     /@[ localname() != Id ] |
                     /descendant::node()/@
                   ) )
)))

Thanks,
Donald
======================================================================
 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]

On Tue, 18 Jun 2002 [email-masked] wrote:

> Date: Tue, 18 Jun 2002 07:26:48 -0400
> From: [email-masked]
> To: IETF-Announce:  ;
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-trade-voucher-lang-03.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.
>
> 	Title		: XML Voucher: Generic Voucher Language
> 	Author(s)	: K. Fujimura, M. Terada
> 	Filename	: draft-ietf-trade-voucher-lang-03.txt
> 	Pages		: 19
> 	Date		: 17-Jun-02
>
> This document specifies rules for defining voucher properties in XML
> syntax. A voucher is a logical entity that represents a right to
> claim goods or services. A voucher can be used to transfer a
> wide-range of electronic-values, including coupons, tickets, loyalty
> points, and gift certificates, which are often necessary to process
> in the course of payment and/or delivery transactions.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-03.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-trade-voucher-lang-03.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-trade-voucher-lang-03.txt".
>
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

Date: Tue, 18 Jun 2002 21:47:45 +0900
From: Ko Fujimura <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-trade-voucher-lang-03.txt
To: [email-masked]
Cc: Ko Fujimura <[email-masked]>

Hello,

We updated the draft as you noticed. The changes we made from the previous 
version are only a few points:

(1) Based on the recent draft [XML-Registry], targetNamespace of XML Voucher 
    was changed from:
         "http://www.ietf.org/rfc/rfcXXXX"
    to:
         "urn:ietf:params:xml:schema:vts-lang"
    Added IANA Consideration section 7 for call IANA to register this 
    schema. 

    [XML-Registry] M. Mealing, "The IETF XML Registry",
    draft-mealling-iana-xmlns-registry-03, November 2001.

(2) Deleted below sentences in 6.8 <Value> because they are too specific:

    Discount: ... "Only one sheet of voucher can be used for a single 
      purchase of the item. The discount values for a single purchase of 
      the item must not exceed the retail price."
    Monetary: ... "Multiple vouchers can be redeemed for purchasing a 
      single item. If the total value of the vouchers exceeds the retail 
      price, changes will be given."

(3) Deleted below sentence in 6.5 <Issuer>, last sentence of the paragraph
    starting from "If the <Issuer> element is omitted ..."

      "The issuer role (responsibility for the contents of the voucher) is 
       delegated to the VTS Provider"

    It was a mistake. The issuer is managed by the VTS and no need to 
    delegate its responsibility to the VTS Provider.

Any comments are welcome.

We are also going to update the VTS-API draft soon. But changes we 
intended for the next version are also minor.

Thanks,

Ko
--------------------------------------------------------------
Dr. Ko Fujimura, NTT Information Sharing Platform Laboratories
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa 239-0847, JAPAN
Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-8329
Email: [email-masked]

Date: Tue, 18 Jun 2002 07:26:48 -0400
From: [email-masked]
Subject: I-D ACTION:draft-ietf-trade-voucher-lang-03.txt
Sender: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]

--Boundary_(ID_gxVGisHxcpBg0xt5+yOpVQ)
Content-type: TEXT/PLAIN

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

	Title		: XML Voucher: Generic Voucher Language
	Author(s)	: K. Fujimura, M. Terada
	Filename	: draft-ietf-trade-voucher-lang-03.txt
	Pages		: 19
	Date		: 17-Jun-02
	
This document specifies rules for defining voucher properties in XML
syntax. A voucher is a logical entity that represents a right to
claim goods or services. A voucher can be used to transfer a
wide-range of electronic-values, including coupons, tickets, loyalty
points, and gift certificates, which are often necessary to process
in the course of payment and/or delivery transactions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-voucher-lang-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-trade-voucher-lang-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-trade-voucher-lang-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_gxVGisHxcpBg0xt5+yOpVQ)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_6lNf4HDcfrYMGhEqyz//6A)"

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-trade-voucher-lang-03.txt

--Boundary_(ID_6lNf4HDcfrYMGhEqyz//6A)
Content-type: Message/External-body; directory=internet-drafts;
 access-type=anon-ftp; site=ftp.ietf.org;
 name=draft-ietf-trade-voucher-lang-03.txt

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

--Boundary_(ID_6lNf4HDcfrYMGhEqyz//6A)--

--Boundary_(ID_gxVGisHxcpBg0xt5+yOpVQ)--

Content-return: allowed
Date: Fri, 14 Jun 2002 11:09:34 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: RE: new ECML v 2 requirements
To: [email-masked]

Since there doesn't seem to have been any objection to these fields, just
discussion on their format, the draft will be updated to add them with some
specification and we can further refine that, if needed.

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 12, 2002 2:26 AM
To: [email-masked]
Subject: RE: new ECML v 2 requirements from Nokia

Hello all,

Below are my comments and clirifications for the intent of our new
requirements.

> > > Ecom_Device_ID
> > > length: 70     Note: alphanumeric unique identifier
> > > (length=IPv6 space)
> 
> Assuming the ID is different for different types, we don't 
> have to worry
> about defining them to closely, just reserving enough space. 
> Presumably
> they are defined in conjuction with the specification of each type.
> 
> > > Ecom_Device_ID_type
> > > Required if Device ID used.
> > > length: 20     Note: name or brand of deviceID system used
> 
> Does there need to be an IANA registry for these? I would 
> think so, for
> interoperability, unless we can use an existing registry such 
> as domain
> names or Ecom_Payment_Card_Type, but that doesn't seem likely.
> 
> If so, this needs to be added to the IANA considerations section.
> Also, what should the initially registered values be?
> 

[LPI] It is assumed that there will be a lot of different types of IDs. By
type we mean brand, user understandable branded device identification. So
for example IPv6_ADDRESS is 
NOT our intent, but instead (example) EASY SWIPE. What we aim at is that
there may be accessories or software to mobile terminals and PC's that is
used as access token at later time. So when paying for 'ticket' the user can
inform the service of the access token he/she has. Service can check if the
access token is recognised by the service, and if so, grant access to user.

As the type is flexible, brand type, there will be situations where the ID
field itself is not unique, so that EASY SWIPE and FAST PASS may have the
same number space in their ID. 

IANA is not needed, services will advertise the type they accept, and
agreements are possible between different type providers for interoperable
use.

> > >
> > > Ecom_Loyalty_Card_Name
> 
> I assume this is intended to be the cardholder name? If so, it should
> probably have the same 30 character length limit.
> 

[LPI] Yes, this is the card holder name.

> > > Ecom_Loyalty_Card_Number
> > > Requried minimum data for loyalty usage.
> > > length:60         Note: Not purely number, number field may
> > > contain also characters (e.g. flight
> > > bonus  cards)
> > >
> > > Ecom_Loyalty_Card_Type
> > > lenght:20		Note: longer text field needed due to
> > > amount of loyalty systems
> 
> See comment above on Ecom_Device_ID_Type.
> 

[LPI] See above for comment on comment on Ecom_Device_ID_Type ;) 

This is also brand named field. I see no reason for registering the loylaty
card types. If a service supports loyalty schemes it will advertise it. If
the brand is not accepted, the service will inform the user but no real harm
is done. 

> > > Ecom_Loyalty_Card_Verification
> 
> Should this be the same 4 character limit as the payment card
> verifiction field?
> 

[LPI] I think that 4 character limit is enough. As the loylaty numbering
scheme is not well defined (no standard) this is just a quess, but even with
very long numbers etc a 4 character verification field, CRC etc seems
enough.

> > >
> > > Ecom_UserData_Country
> > > length:20
> 
> Why can't this be an ISO 2 letter ISO Country code as already used in
> Ecom_x_Postal_CountryCode for various x?
> 
> > > Ecom_UserData_Language
> > > length:20
> 
> It needs to be specified what format this is. I would recommend IETF
> country codes as per RFC 3282, In which case, although most would be
> short, you might allow a little more length for odd cases.
> 

Well defined codes would be good. This has caused a lot of mails, and one of
the masked for the intent behind this country field. What we aimed for, is
that the service can be given information on user location. Service can give
more user specific content (new of Finland) or service redirect to local
subsidiary etc. Address field usage for this is problematic, as on the user
interface it would seem that the service is already asking for very user
specific, private information -- the address. As this field and information
would be used at very first access to pages, at the start of a session to
service -- the user is not ready to give the address yet.

As such, I see that a new field is needed for this information, but the
syntax of this field could be a country code as specified in ISO. Usage for
this legislation finding -- if I have understood the mails correctly --
would be on the same lines as our intended usage. Service can find out
taxation, legislation issues at very early phase and thus possibly offer
goods not allowed or profitable for all areas/countries.

Sincerely,
- Lauri Piikivi

Date: Wed, 12 Jun 2002 09:26:23 +0300
From: [email-masked]
Subject: RE: new ECML v 2 requirements from Nokia
To: [email-masked]
content-class: urn:content-classes:message

Hello all,

Below are my comments and clirifications for the intent of our new re=
quirements.

> > > Ecom_Device_ID
> > > length: 70     Note: alphanumeric unique identifier
> > > (length=3DIPv6 space)
>=20
> Assuming the ID is different for different types, we don't=20
> have to worry
> about defining them to closely, just reserving enough space.=20
> Presumably
> they are defined in conjuction with the specification of each type.
>=20
> > > Ecom_Device_ID_type
> > > Required if Device ID used.
> > > length: 20     Note: name or brand of deviceID system used
>=20
> Does there need to be an IANA registry for these? I would=20
> think so, for
> interoperability, unless we can use an existing registry such=20
> as domain
> names or Ecom_Payment_Card_Type, but that doesn't seem likely.
>=20
> If so, this needs to be added to the IANA considerations section.
> Also, what should the initially registered values be?
>=20

[LPI] It is assumed that there will be a lot of different types of ID=
s. By type we mean brand, user understandable branded device identifi=
cation. So for example IPv6_ADDRESS is=20
NOT our intent, but instead (example) EASY SWIPE. What we aim at is t=
hat there may be accessories or software to mobile terminals and PC's=
 that is used as access token at later time. So when paying for 'tick=
et' the user can inform the service of the access token he/she has. S=
ervice can check if the access token is recognised by the service, an=
d if so, grant access to user.

As the type is flexible, brand type, there will be situations where t=
he ID field itself is not unique, so that EASY SWIPE and FAST PASS ma=
y have the same number space in their ID.=20

IANA is not needed, services will advertise the type they accept, and=
 agreements are possible between different type providers for interop=
erable use.

> > >
> > > Ecom_Loyalty_Card_Name
>=20
> I assume this is intended to be the cardholder name? If so, it shou=
ld
> probably have the same 30 character length limit.
>=20

[LPI] Yes, this is the card holder name.

> > > Ecom_Loyalty_Card_Number
> > > Requried minimum data for loyalty usage.
> > > length:60         Note: Not purely number, number field may
> > > contain also characters (e.g. flight
> > > bonus  cards)
> > >
> > > Ecom_Loyalty_Card_Type
> > > lenght:20=09=09Note: longer text field needed due to
> > > amount of loyalty systems
>=20
> See comment above on Ecom_Device_ID_Type.
>=20

[LPI] See above for comment on comment on Ecom_Device_ID_Type ;)=20

This is also brand named field. I see no reason for registering the l=
oylaty card types. If a service supports loyalty schemes it will adve=
rtise it. If the brand is not accepted, the service will inform the u=
ser but no real harm is done.=20

> > > Ecom_Loyalty_Card_Verification
>=20
> Should this be the same 4 character limit as the payment card
> verifiction field?
>=20

[LPI] I think that 4 character limit is enough. As the loylaty number=
ing scheme is not well defined (no standard) this is just a quess, bu=
t even with very long numbers etc a 4 character verification field, C=
RC etc seems enough.

> > >
> > > Ecom_UserData_Country
> > > length:20
>=20
> Why can't this be an ISO 2 letter ISO Country code as already used =
in
> Ecom_x_Postal_CountryCode for various x?
>=20
> > > Ecom_UserData_Language
> > > length:20
>=20
> It needs to be specified what format this is. I would recommend IET=
F
> country codes as per RFC 3282, In which case, although most would b=
e
> short, you might allow a little more length for odd cases.
>=20

Well defined codes would be good. This has caused a lot of mails, and=
 one of the masked for the intent behind this country field. What we =
aimed for, is that the service can be given information on user locat=
ion. Service can give more user specific content (new of Finland) or =
service redirect to local subsidiary etc. Address field usage for thi=
s is problematic, as on the user interface it would seem that the ser=
vice is already asking for very user specific, private information --=
 the address. As this field and information would be used at very fir=
st access to pages, at the start of a session to service -- the user =
is not ready to give the address yet.

As such, I see that a new field is needed for this information, but t=
he syntax of this field could be a country code as specified in ISO. =
Usage for this legislation finding -- if I have understood the mails =
correctly -- would be on the same lines as our intended usage. Servic=
e can find out taxation, legislation issues at very early phase and t=
hus possibly offer goods not allowed or profitable for all areas/coun=
tries.

Sincerely,
- Lauri Piikivi

Content-return: allowed
Date: Tue, 11 Jun 2002 21:20:09 +0100
From: Ronald Duncan <[email-masked]>
Subject: RE: new ECML v 2 requirements from Nokia
To: "'Burdett, David'" <[email-masked]>, 'Chris Smith' <[email-masked]>, Donald Eastlake 3rd <[email-masked]>
Cc: Eric Brunner <[email-masked]>, [email-masked], [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_ZcDntAufsen6iyWJjpjMkQ)
Content-type: text/plain; charset=iso-8859-1

We are just updating our tax and shipping calculator so this is quite
relevant to us at the moment.
 
Currently the ISO codes give us a reasonable number of countries.  However
there are a number of different issues.
 
E.g. Isle of Man has different tax implications for shipping from the UK and
may have different costs.
 
It does not appear to have an ISO 2 letter or 3 letter code but has a
Numerical Code.  The ISO Alpha 3 code does seem more comprehensive than the
2 letter codes however it is not freely available.
http://unstats.un.org/unsd/methods/m49/m49alpha.htm
<http://unstats.un.org/unsd/methods/m49/m49alpha.htm> 
vs
http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/inde
x.html
<http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/ind
ex.html>   <http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/> 
 
The ISO codes are easy to find however, I had a quick trawl 
through http://www.xcbl.org <http://www.xcbl.org>  
and http://www.oasis-open.org/committees/ubl/
<http://www.oasis-open.org/committees/ubl/> 
 
and I was not able to find the current Othercountries list which is clearly
going to be vital for interoperability.
 
A link would be much appreciated.
 
There are large numbers of principalities and tax havens in the world and a
common way of referencing them would be nice.
 
Regards -- Ronald

-----Original Message-----
From: Burdett, David [mailto:[email-masked]]
Sent: 11 June 2002 16:02
To: 'Chris Smith'; Donald Eastlake 3rd
Cc: Eric Brunner; [email-masked]; [email-masked];
[email-masked]
Subject: RE: new ECML v 2 requirements from Nokia

Chris, Donald, Eric and others 

It's a sad but real fact that Standards groups always lag behind the real
world. ISO with their country codes (and currency codes) is no exception.
However the alternative of not following any standard is worse since you
don't get the interoperability we all seek. 

We've faced this exact problem several times before and came up with the
following solution which, although not ideal actually works and is being
used in eCommerce today which. It involves the use of two codes:

1. CountryCode which MUST contain either an ISO3166-1997 compliant country
code or the text "Other" 
2. CountryCodeOther, which contains some other, mutually agreed code to
identify a country if "CountryCode" on those few occasions when an ISO3166
code will not suffice. It is only used if CountryCode contains the text
"Other".

This idea is taken from the XML Common Business Language - xCBL (
http://www.xcbl.org <http://www.xcbl.org> ) which is a set of XML Business
Document definitions that Commerce One developed and is now being taken as
the basis for the UBL standards initiative (
http://www.oasis-open.org/committees/ubl/
<http://www.oasis-open.org/committees/ubl/> ).

We often come under pressure to add new country codes and, even more, new
currency codes, to xCBL but have always resisted since it is impossible to
do this in a fair way. We simply say, when ISO comes up with a new list we
will use it, but not until.

I hope these ideas help. 

David 

-----Original Message----- 
From: Chris Smith [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Monday, June 10, 2002 9:47 PM 
To: Donald Eastlake 3rd 
Cc: Eric Brunner; [email-masked]; [email-masked]; 
[email-masked] 
Subject: Re: new ECML v 2 requirements from Nokia 

Previously, Donald Eastlake 3rd and Eric Brunner wrote: 

> > The big issue is jurisdiction, from which the regulatory circumstances
and 
> > taxation consequences of a transaction arise. 

> > > I'm not quite so clear on country codes but if you include the codes 
> > > reserved in ISO 3166 but not actually issued, I think you cover the
entities 
> > > in the Universal Postal Union.  Can you give an example of a
jurisdiction 
> > > not covered by that which would be of any significance in this
protocol? 

There needs to be a decision regarding a geographical basis vs a 
political basis. ISO 3166 refers to "areas of geopolitical 
interest", and won't completely resolve the issue for you. 

Many embassies are in Washington DC, U.S.A, but the embassies 
proper are considered sovereign. Jurisdiction and location 
can be independent at times. 

> The Navajo Nation, etc., are subordinate entities that are 
> "soveriegn" only to the extent that the US allows. 

Subject to occasional court decisions, both ways... 

> Since you talk about tax consequences, it can vary in the US 
> not just on state/indian-nation but also city, county, 
> special districts, and who knows what else... 

Don't forget parish. Yes, accomodating this could be difficult. 
If it was easy we would be done by now... 

> So you don't like iso3166. What exactly is your alternative? You make a 
> reasonable argument that there is some benefit in being able to extend 
> iso3166 codes, the same way the IETF standard lets you extend ISO 
> language codes, 

Even ISO 3166 documents some of the 'extensions' - witness the 
addition of "ca-nu". But it also clear that in some cases, the 
chain of jurisdiction does not flow all the way back to "ca". 

So, the choice would appear to be between 

1) ISO 3166 codes and restricting the field as such 
2) allow ISO and private codes with a way to distinguish 
3) provide one ISO field and one 'Jurisdiction' field 

1) is tough and inflexible 
2) tends towards non-interoperable 
3) is growing the complexity 

It depends on what the goal is - what IS the goal for 
this field, anyway? 

---------------------------------------------------------------------- 
Chris Smith                                       <[email-masked]> 

--Boundary_(ID_ZcDntAufsen6iyWJjpjMkQ)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso=
-8859-1">
<TITLE>RE: new ECML v 2 requirements from Nokia</TITLE>

<META content=3D"MSHTML 5.00.3315.2870" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN class=3D777493=
319-11062002>We are=20
just updating our tax and shipping calculator so this is quite releva=
nt to us at=20
the moment.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002>Currently the ISO codes give us a reasonab=
le number of=20
countries.&nbsp; However there are a number of different=20
issues.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN class=3D777493=
319-11062002>E.g.=20
Isle of Man has different tax implications for shipping from the UK a=
nd may have=20
different costs.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN class=3D777493=
319-11062002>It=20
does not appear to have an ISO 2 letter or 3 letter code but has a Nu=
merical=20
Code.&nbsp; The ISO Alpha 3 code does seem more comprehensive than th=
e 2 letter=20
codes however it is not freely available.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN class=3D777493=
319-11062002><A=20
href=3D"http://unstats.un.org/unsd/methods/m49/m49alpha.htm">http://u=
nstats.un.org/unsd/methods/m49/m49alpha.htm</A></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002>vs</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN class=3D777493=
319-11062002><A=20
href=3D"http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-=
code-lists/index.html">http://www.iso.ch/iso/en/prods-services/iso316=
6ma/02iso-3166-code-lists/index.html</A><A=20
href=3D"http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/"></A><=
/SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN class=3D777493=
319-11062002>The=20
ISO codes are easy to find however, I had a quick trawl </SPAN></FONT=
></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002>through <A href=3D"http://www.xcbl.org"=
=20
target=3D_blank>http://www.xcbl.org</A>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN class=3D777493=
319-11062002>and <A=20
href=3D"http://www.oasis-open.org/committees/ubl/">http://www.oasis-o=
pen.org/committees/ubl/</A></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN class=3D777493=
319-11062002>and I=20
was not able to find the current Othercountries list which is clearly=
 going to=20
be vital for interoperability.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN class=3D777493=
319-11062002>A link=20
would be much appreciated.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN class=3D777493=
319-11062002>There=20
are large numbers of principalities and tax havens in the world and a=
 common way=20
of referencing them would be nice.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D777493319-11062002>Regards -- Ronald</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIG=
HT: 0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT face=
=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Burdett, David=
=20
  [mailto:[email-masked]]<BR><B>Sent:</B> 11 June 2002=
=20
  16:02<BR><B>To:</B> 'Chris Smith'; Donald Eastlake 3rd<BR><B>Cc:</B=
> Eric=20
  Brunner; [email-masked]; [email-masked];=20
  [email-masked]<BR><B>Subject:</B> RE: new ECML v 2 req=
uirements=20
  from Nokia<BR><BR></DIV></FONT>
  <P><FONT size=3D2>Chris, Donald, Eric and others</FONT> </P>
  <P><FONT size=3D2>It's a sad but real fact that Standards groups al=
ways lag=20
  behind the real world. ISO with their country codes (and currency c=
odes) is no=20
  exception. However the alternative of not following any standard is=
 worse=20
  since you don't get the interoperability we all seek. </FONT></P>
  <P><FONT size=3D2>We've faced this exact problem several times befo=
re and came=20
  up with the following solution which, although not ideal actually w=
orks and is=20
  being used in eCommerce today which. It involves the use of two=
=20
  codes:</FONT></P>
  <P><FONT size=3D2>1. CountryCode which MUST contain either an ISO31=
66-1997=20
  compliant country code or the text "Other"</FONT> <BR><FONT size=
=3D2>2.=20
  CountryCodeOther, which contains some other, mutually agreed code t=
o identify=20
  a country if "CountryCode" on those few occasions when an ISO3166 c=
ode will=20
  not suffice. It is only used if CountryCode contains the text=20
  "Other".</FONT></P>
  <P><FONT size=3D2>This idea is taken from the XML Common Business L=
anguage -=20
  xCBL (<A href=3D"http://www.xcbl.org" target=3D_blank>http://www.xc=
bl.org</A>)=20
  which is a set of XML Business Document definitions that Commerce O=
ne=20
  developed and is now being taken as the basis for the UBL standards=
 initiative=20
  (<A href=3D"http://www.oasis-open.org/committees/ubl/"=20
  target=3D_blank>http://www.oasis-open.org/committees/ubl/</A>).</FO=
NT></P>
  <P><FONT size=3D2>We often come under pressure to add new country c=
odes and,=20
  even more, new currency codes, to xCBL but have always resisted sin=
ce it is=20
  impossible to do this in a fair way. We simply say, when ISO comes =
up with a=20
  new list we will use it, but not until.</FONT></P>
  <P><FONT size=3D2>I hope these ideas help.</FONT> </P>
  <P><FONT size=3D2>David</FONT> </P><BR>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT size=
=3D2>From: Chris=20
  Smith [<A=20
  href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</=
FONT>=20
  <BR><FONT size=3D2>Sent: Monday, June 10, 2002 9:47 PM</FONT> <BR><=
FONT=20
  size=3D2>To: Donald Eastlake 3rd</FONT> <BR><FONT size=3D2>Cc: Eric=
 Brunner;=20
  [email-masked]; [email-masked];</FONT> <BR><FON=
T=20
  size=3D2>[email-masked]</FONT> <BR><FONT size=3D2>Subj=
ect: Re: new=20
  ECML v 2 requirements from Nokia</FONT> </P><BR>
  <P><FONT size=3D2>Previously, Donald Eastlake 3rd and Eric Brunner =
wrote:</FONT>=20
  </P>
  <P><FONT size=3D2>&gt; &gt; The big issue is jurisdiction, from whi=
ch the=20
  regulatory circumstances and</FONT> <BR><FONT size=3D2>&gt; &gt; ta=
xation=20
  consequences of a transaction arise.</FONT> </P>
  <P><FONT size=3D2>&gt; &gt; &gt; I'm not quite so clear on country =
codes but if=20
  you include the codes</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; rese=
rved in ISO=20
  3166 but not actually issued, I think you cover the entities</FONT>=
 <BR><FONT=20
  size=3D2>&gt; &gt; &gt; in the Universal Postal Union.&nbsp; Can yo=
u give an=20
  example of a jurisdiction</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
not covered=20
  by that which would be of any significance in this protocol?</FONT>=
 </P>
  <P><FONT size=3D2>There needs to be a decision regarding a geograph=
ical basis vs=20
  a</FONT> <BR><FONT size=3D2>political basis. ISO 3166 refers to "ar=
eas of=20
  geopolitical</FONT> <BR><FONT size=3D2>interest", and won't complet=
ely resolve=20
  the issue for you.</FONT> </P>
  <P><FONT size=3D2>Many embassies are in Washington DC, U.S.A, but t=
he=20
  embassies</FONT> <BR><FONT size=3D2>proper are considered sovereign=
.=20
  Jurisdiction and location</FONT> <BR><FONT size=3D2>can be independ=
ent at=20
  times.</FONT> </P>
  <P><FONT size=3D2>&gt; The Navajo Nation, etc., are subordinate ent=
ities that=20
  are</FONT> <BR><FONT size=3D2>&gt; "soveriegn" only to the extent t=
hat the US=20
  allows.</FONT> </P>
  <P><FONT size=3D2>Subject to occasional court decisions, both ways.=
..</FONT>=20
</P>
  <P><FONT size=3D2>&gt; Since you talk about tax consequences, it ca=
n vary in the=20
  US</FONT> <BR><FONT size=3D2>&gt; not just on state/indian-nation b=
ut also city,=20
  county,</FONT> <BR><FONT size=3D2>&gt; special districts, and who k=
nows what=20
  else...</FONT> </P>
  <P><FONT size=3D2>Don't forget parish. Yes, accomodating this could=
 be=20
  difficult.</FONT> <BR><FONT size=3D2>If it was easy we would be don=
e by=20
  now...</FONT> </P>
  <P><FONT size=3D2>&gt; So you don't like iso3166. What exactly is y=
our=20
  alternative? You make a</FONT> <BR><FONT size=3D2>&gt; reasonable a=
rgument that=20
  there is some benefit in being able to extend</FONT> <BR><FONT size=
=3D2>&gt;=20
  iso3166 codes, the same way the IETF standard lets you extend ISO</=
FONT>=20
  <BR><FONT size=3D2>&gt; language codes,</FONT> </P>
  <P><FONT size=3D2>Even ISO 3166 documents some of the 'extensions' =
- witness=20
  the</FONT> <BR><FONT size=3D2>addition of "ca-nu". But it also clea=
r that in=20
  some cases, the</FONT> <BR><FONT size=3D2>chain of jurisdiction doe=
s not flow=20
  all the way back to "ca".</FONT> </P>
  <P><FONT size=3D2>So, the choice would appear to be between</FONT> =
</P>
  <P><FONT size=3D2>1) ISO 3166 codes and restricting the field as su=
ch</FONT>=20
  <BR><FONT size=3D2>2) allow ISO and private codes with a way to=
=20
  distinguish</FONT> <BR><FONT size=3D2>3) provide one ISO field and =
one=20
  'Jurisdiction' field</FONT> </P>
  <P><FONT size=3D2>1) is tough and inflexible</FONT> <BR><FONT size=
=3D2>2) tends=20
  towards non-interoperable</FONT> <BR><FONT size=3D2>3) is growing t=
he=20
  complexity</FONT> </P>
  <P><FONT size=3D2>It depends on what the goal is - what IS the goal=
 for</FONT>=20
  <BR><FONT size=3D2>this field, anyway?</FONT> </P>
  <P><FONT=20
  size=3D2>----------------------------------------------------------=
------------</FONT>=20
  <BR><FONT size=3D2>Chris=20
  Smith&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &lt;[email-masked]&gt;</FONT> </P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_ZcDntAufsen6iyWJjpjMkQ)--

Date: Tue, 11 Jun 2002 15:46:22 -0400
From: Eric Brunner <[email-masked]>
Subject: Re: new ECML v 2 requirements from Nokia
To: "Burdett, David" <[email-masked]>
Cc: 'Chris Smith' <[email-masked]>, Donald Eastlake 3rd <[email-masked]>, Eric Brunner <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]

David,

An escape mechanism from a iso3166-constrained interpretation of a series of
two or more octets is fine, assuming that iso3166 was a manditory referent.

When Donald, Bill and I (but mostly Donald and I) went over the equivalent
problem in Domain Name System (DNS) IANA Considerations (BCP 0042), we found
that we could reserve the two-octet label-space without having to cite 3166.

There we were forced to consider the problem of unique identifiers and the
legacy code base that knew the identifiers consisted of 16 contiguous bits,
interpreted as octet-aligned data, and letters-digits-or-hyphen, in ASCII.
We still don't have any basis to judge whether or not the management of the
DNS root was effected one way or another by not citing 3166. We don't appear
to have caused an instance of non-interoperability.

Here we are just attempting to create an identifer with no compactness
properties that force us to use binary labels, or anything less compact
than strings -- the requirement of two octet (ASCII) strings seems to be
foreign to the problem at hand.

The degree of implementation complexity that seperates a two-octet lookup
table with sparce (240) values, and shell-completion isn't compelling.

If the 3166 reference is optional (which is how we solved this problem in
the XML stream for provisioning DNS TLD registries in PROVREG [1]), then
the problem is solved.

Eric

[1]  EPP Contact mapping, Sec. 2.4.1 Street, City, and State or Province
     draft-ietf-provreg-epp-contact-04.txt

Content-return: allowed
Date: Tue, 11 Jun 2002 08:01:45 -0700
From: "Burdett, David" <[email-masked]>
Subject: RE: new ECML v 2 requirements from Nokia
To: 'Chris Smith' <[email-masked]>, Donald Eastlake 3rd <[email-masked]>
Cc: Eric Brunner <[email-masked]>, [email-masked], [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_FNnyq01jxvLU1gUgC4McIg)
Content-type: text/plain

Chris, Donald, Eric and others

It's a sad but real fact that Standards groups always lag behind the real
world. ISO with their country codes (and currency codes) is no exception.
However the alternative of not following any standard is worse since you
don't get the interoperability we all seek. 

We've faced this exact problem several times before and came up with the
following solution which, although not ideal actually works and is being
used in eCommerce today which. It involves the use of two codes:

1. CountryCode which MUST contain either an ISO3166-1997 compliant country
code or the text "Other"
2. CountryCodeOther, which contains some other, mutually agreed code to
identify a country if "CountryCode" on those few occasions when an ISO3166
code will not suffice. It is only used if CountryCode contains the text
"Other".

This idea is taken from the XML Common Business Language - xCBL
(http://www.xcbl.org) which is a set of XML Business Document definitions
that Commerce One developed and is now being taken as the basis for the UBL
standards initiative (http://www.oasis-open.org/committees/ubl/).

We often come under pressure to add new country codes and, even more, new
currency codes, to xCBL but have always resisted since it is impossible to
do this in a fair way. We simply say, when ISO comes up with a new list we
will use it, but not until.

I hope these ideas help.

David

-----Original Message-----
From: Chris Smith [mailto:[email-masked]]
Sent: Monday, June 10, 2002 9:47 PM
To: Donald Eastlake 3rd
Cc: Eric Brunner; [email-masked]; [email-masked];
[email-masked]
Subject: Re: new ECML v 2 requirements from Nokia

Previously, Donald Eastlake 3rd and Eric Brunner wrote:

> > The big issue is jurisdiction, from which the regulatory circumstances
and
> > taxation consequences of a transaction arise.

> > > I'm not quite so clear on country codes but if you include the codes
> > > reserved in ISO 3166 but not actually issued, I think you cover the
entities
> > > in the Universal Postal Union.  Can you give an example of a
jurisdiction
> > > not covered by that which would be of any significance in this
protocol?

There needs to be a decision regarding a geographical basis vs a
political basis. ISO 3166 refers to "areas of geopolitical
interest", and won't completely resolve the issue for you.

Many embassies are in Washington DC, U.S.A, but the embassies
proper are considered sovereign. Jurisdiction and location
can be independent at times.

> The Navajo Nation, etc., are subordinate entities that are
> "soveriegn" only to the extent that the US allows.

Subject to occasional court decisions, both ways...

> Since you talk about tax consequences, it can vary in the US
> not just on state/indian-nation but also city, county,
> special districts, and who knows what else...

Don't forget parish. Yes, accomodating this could be difficult.
If it was easy we would be done by now...

> So you don't like iso3166. What exactly is your alternative? You make a
> reasonable argument that there is some benefit in being able to extend
> iso3166 codes, the same way the IETF standard lets you extend ISO
> language codes,

Even ISO 3166 documents some of the 'extensions' - witness the
addition of "ca-nu". But it also clear that in some cases, the
chain of jurisdiction does not flow all the way back to "ca".

So, the choice would appear to be between

1) ISO 3166 codes and restricting the field as such
2) allow ISO and private codes with a way to distinguish
3) provide one ISO field and one 'Jurisdiction' field

1) is tough and inflexible
2) tends towards non-interoperable
3) is growing the complexity

It depends on what the goal is - what IS the goal for
this field, anyway?

----------------------------------------------------------------------
Chris Smith                                       <[email-masked]>

--Boundary_(ID_FNnyq01jxvLU1gUgC4McIg)
Content-type: text/html
Content-transfer-encoding: QUOTED-PRINTABLE

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3DUS-=
ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 5.5.26=
53.12">
<TITLE>RE: new ECML v 2 requirements from Nokia</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Chris, Donald, Eric and others</FONT>
</P>

<P><FONT SIZE=3D2>It's a sad but real fact that Standards groups alwa=
ys lag behind the real world. ISO with their country codes (and curre=
ncy codes) is no exception. However the alternative of not following =
any standard is worse since you don't get the interoperability we all=
 seek. </FONT></P>

<P><FONT SIZE=3D2>We've faced this exact problem several times before=
 and came up with the following solution which, although not ideal ac=
tually works and is being used in eCommerce today which. It involves =
the use of two codes:</FONT></P>

<P><FONT SIZE=3D2>1. CountryCode which MUST contain either an ISO3166=
-1997 compliant country code or the text &quot;Other&quot;</FONT>
<BR><FONT SIZE=3D2>2. CountryCodeOther, which contains some other, mu=
tually agreed code to identify a country if &quot;CountryCode&quot; o=
n those few occasions when an ISO3166 code will not suffice. It is on=
ly used if CountryCode contains the text &quot;Other&quot;.</FONT></P=
>

<P><FONT SIZE=3D2>This idea is taken from the XML Common Business Lan=
guage - xCBL (<A HREF=3D"http://www.xcbl.org" TARGET=3D"_blank">http:=
//www.xcbl.org</A>) which is a set of XML Business Document definitio=
ns that Commerce One developed and is now being taken as the basis fo=
r the UBL standards initiative (<A HREF=3D"http://www.oasis-open.org/=
committees/ubl/" TARGET=3D"_blank">http://www.oasis-open.org/committe=
es/ubl/</A>).</FONT></P>

<P><FONT SIZE=3D2>We often come under pressure to add new country cod=
es and, even more, new currency codes, to xCBL but have always resist=
ed since it is impossible to do this in a fair way. We simply say, wh=
en ISO comes up with a new list we will use it, but not until.</FONT>=
</P>

<P><FONT SIZE=3D2>I hope these ideas help.</FONT>
</P>

<P><FONT SIZE=3D2>David</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Chris Smith [<A HREF=3D"mailto:smith@interlo=
g.com">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, June 10, 2002 9:47 PM</FONT>
<BR><FONT SIZE=3D2>To: Donald Eastlake 3rd</FONT>
<BR><FONT SIZE=3D2>Cc: Eric Brunner; [email-masked]; Chris.B=
[email-masked];</FONT>
<BR><FONT SIZE=3D2>[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: new ECML v 2 requirements from Nokia<=
/FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Previously, Donald Eastlake 3rd and Eric Brunner wr=
ote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; The big issue is jurisdiction, from which=
 the regulatory circumstances and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; taxation consequences of a transaction a=
rise.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; &gt; I'm not quite so clear on country co=
des but if you include the codes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; reserved in ISO 3166 but not actual=
ly issued, I think you cover the entities</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; in the Universal Postal Union.&nbsp=
; Can you give an example of a jurisdiction</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; not covered by that which would be =
of any significance in this protocol?</FONT>
</P>

<P><FONT SIZE=3D2>There needs to be a decision regarding a geographic=
al basis vs a</FONT>
<BR><FONT SIZE=3D2>political basis. ISO 3166 refers to &quot;areas of=
 geopolitical</FONT>
<BR><FONT SIZE=3D2>interest&quot;, and won't completely resolve the i=
ssue for you.</FONT>
</P>

<P><FONT SIZE=3D2>Many embassies are in Washington DC, U.S.A, but the=
 embassies</FONT>
<BR><FONT SIZE=3D2>proper are considered sovereign. Jurisdiction and =
location</FONT>
<BR><FONT SIZE=3D2>can be independent at times.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; The Navajo Nation, etc., are subordinate entit=
ies that are</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;soveriegn&quot; only to the extent that=
 the US allows.</FONT>
</P>

<P><FONT SIZE=3D2>Subject to occasional court decisions, both ways...=
</FONT>
</P>

<P><FONT SIZE=3D2>&gt; Since you talk about tax consequences, it can =
vary in the US</FONT>
<BR><FONT SIZE=3D2>&gt; not just on state/indian-nation but also city=
, county,</FONT>
<BR><FONT SIZE=3D2>&gt; special districts, and who knows what else...=
</FONT>
</P>

<P><FONT SIZE=3D2>Don't forget parish. Yes, accomodating this could b=
e difficult.</FONT>
<BR><FONT SIZE=3D2>If it was easy we would be done by now...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; So you don't like iso3166. What exactly is you=
r alternative? You make a</FONT>
<BR><FONT SIZE=3D2>&gt; reasonable argument that there is some benefi=
t in being able to extend</FONT>
<BR><FONT SIZE=3D2>&gt; iso3166 codes, the same way the IETF standard=
 lets you extend ISO</FONT>
<BR><FONT SIZE=3D2>&gt; language codes,</FONT>
</P>

<P><FONT SIZE=3D2>Even ISO 3166 documents some of the 'extensions' - =
witness the</FONT>
<BR><FONT SIZE=3D2>addition of &quot;ca-nu&quot;. But it also clear t=
hat in some cases, the</FONT>
<BR><FONT SIZE=3D2>chain of jurisdiction does not flow all the way ba=
ck to &quot;ca&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>So, the choice would appear to be between</FONT>
</P>

<P><FONT SIZE=3D2>1) ISO 3166 codes and restricting the field as such=
</FONT>
<BR><FONT SIZE=3D2>2) allow ISO and private codes with a way to disti=
nguish</FONT>
<BR><FONT SIZE=3D2>3) provide one ISO field and one 'Jurisdiction' fi=
eld</FONT>
</P>

<P><FONT SIZE=3D2>1) is tough and inflexible</FONT>
<BR><FONT SIZE=3D2>2) tends towards non-interoperable</FONT>
<BR><FONT SIZE=3D2>3) is growing the complexity</FONT>
</P>

<P><FONT SIZE=3D2>It depends on what the goal is - what IS the goal f=
or</FONT>
<BR><FONT SIZE=3D2>this field, anyway?</FONT>
</P>

<P><FONT SIZE=3D2>---------------------------------------------------=
-------------------</FONT>
<BR><FONT SIZE=3D2>Chris Smith&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;smith@interlo=
g.com&gt;</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_FNnyq01jxvLU1gUgC4McIg)--

Date: Tue, 11 Jun 2002 10:17:48 -0400
From: Eric Brunner <[email-masked]>
Subject: Re: new ECML v 2 requirements from Nokia
To: Donald Eastlake 3rd <[email-masked]>
Cc: Eric Brunner <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]

Donald,

> Whether you like the situation or not, the Palestinian Authority

We don't dork with ARIN/RIPE/APNIC addr allocations because some State
has a preference for negative-allocation to a competitor.
We don't dork with the IANA root because some State wants to edit it.
We don't dork with BGP4 because some State wants to prevent peering to
a competitor.

We are neutral, or as neutral as we are conscious of how mechanism
is distorted by policy. States don't define the scope of correct
function by a protocol, even an application protocol.

Some octets for an identifier. Is Big. Fine.
Two octets interpreted as 16 bits. Is Still Big. Fine.
Two octets restricted to ASCII isalpha(). Not Is Big. Worry.
Two octets restricted to ASCII isalpha() and restricted to fewer than
300 values, over a hundred of which are absolutely bogus for a 1st-world
financial infrastructure except as tax dodges and worse, and which makes
extension elsewhere manditory. Ouch.

> So you don't like iso3166. What exactly is your alternative? 

Don't overspecify. Use MAY nor MUST. It isn't our business to codify the
passions of Kings and Presidents, or make the net safe for Nation States.

I object to iso3166 as unnecessary overspecification of the range of
identifiers of a two- (or more) octet, octet-alligned field. You've
noted the objection, so we're probably done.

Eric

Date: Tue, 11 Jun 2002 00:47:29 -0400 (Eastern Daylight Time)
From: Chris Smith <[email-masked]>
Subject: Re: new ECML v 2 requirements from Nokia
To: Donald Eastlake 3rd <[email-masked]>
Cc: Eric Brunner <[email-masked]>, [email-masked], [email-masked], [email-masked]

Previously, Donald Eastlake 3rd and Eric Brunner wrote:

> > The big issue is jurisdiction, from which the regulatory circumstances and
> > taxation consequences of a transaction arise.

> > > I'm not quite so clear on country codes but if you include the codes
> > > reserved in ISO 3166 but not actually issued, I think you cover the entities
> > > in the Universal Postal Union.  Can you give an example of a jurisdiction
> > > not covered by that which would be of any significance in this protocol?

There needs to be a decision regarding a geographical basis vs a
political basis. ISO 3166 refers to "areas of geopolitical
interest", and won't completely resolve the issue for you.

Many embassies are in Washington DC, U.S.A, but the embassies
proper are considered sovereign. Jurisdiction and location
can be independent at times.

> The Navajo Nation, etc., are subordinate entities that are
> "soveriegn" only to the extent that the US allows.

Subject to occasional court decisions, both ways...

> Since you talk about tax consequences, it can vary in the US
> not just on state/indian-nation but also city, county,
> special districts, and who knows what else...

Don't forget parish. Yes, accomodating this could be difficult.
If it was easy we would be done by now...

> So you don't like iso3166. What exactly is your alternative? You make a
> reasonable argument that there is some benefit in being able to extend
> iso3166 codes, the same way the IETF standard lets you extend ISO
> language codes,

Even ISO 3166 documents some of the 'extensions' - witness the
addition of "ca-nu". But it also clear that in some cases, the
chain of jurisdiction does not flow all the way back to "ca".

So, the choice would appear to be between

1) ISO 3166 codes and restricting the field as such
2) allow ISO and private codes with a way to distinguish
3) provide one ISO field and one 'Jurisdiction' field

1) is tough and inflexible
2) tends towards non-interoperable
3) is growing the complexity

It depends on what the goal is - what IS the goal for
this field, anyway?

----------------------------------------------------------------------
Chris Smith                                       <[email-masked]>

Date: Mon, 10 Jun 2002 23:35:31 -0400 (EDT)
From: Donald Eastlake 3rd <[email-masked]>
Subject: Re: new ECML v 2 requirements from Nokia
To: Eric Brunner <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

Hi,

On Mon, 10 Jun 2002, Eric Brunner wrote:

> Date: Mon, 10 Jun 2002 11:30:42 -0400
> From: Eric Brunner <[email-masked]>
> To: Eastlake III Donald-LDE008 <[email-masked]>
> Cc: 'Eric Brunner' <[email-masked]>, [email-masked],
>      [email-masked], [email-masked],
>      [email-masked]
> Subject: Re: new ECML v 2 requirements from Nokia
>
> Donald,
>
> The big issue is jurisdiction, from which the regulatory circumstances and
> taxation consequences of a transaction arise.
>
> > I'm not quite so clear on country codes but if you include the codes
> > reserved in ISO 3166 but not actually issued, I think you cover the entities
> > in the Universal Postal Union.  Can you give an example of a jurisdiction
> > not covered by that which would be of any significance in this protocol?
>
> The Navajo Nation is vastly larger than the Vatican State, Monacco, Pitcarn's
> Island, the Channel Islands, the Sechyelles, and a dozen Pacific Nations ...
> combined. The Pequot Nation is vastly wealthier than some of those also.
>
> To limit the territorial jurisdiction identifiers to the criteria set by the
> DIN makes two-byte comparison easy, but it subordinates use to "states".

The Navajo Nation, etc., are subordinate entities that are "soveriegn"
only to the extent that the US allows. In this regard, it is not clear
to me that they are different from states or territories of the US.
Since you talk about tax consequences, it can vary in the US not just on
state/indian-nation but also city, county, special districts, and who
knows what else...

> Tell me how I can use thie protocol if the trading community consists of
> financial clearinghouse operating companies located within the soverign
> indigenous nations of North America (I already know the answer for soverign
> colonial nations).

US law prevails in the cases where the US has decided it is important
enough. When the law can vary and this is important, you would need a
subdesignator under the country code.

> > This protocol will only be interoperable to the extent that field values are
> > well defined. There is nothing wrong with having non-interoperable private
> > values and extensions, but I believe we should strive to have an
> > interoperable core of values.
>
> We shouldn't use iso3166 unless there really is no alternative. Until last
> year you couldn't even find Palestine in 3166.

Whether you like the situation or not, the Palestinian Authority /
Occupied Palestinian Territories is a subordinate sovereignty to Israel
and has just as much sovereignty as Isreal permits, as recent events
have shown.

So you don't like iso3166. What exactly is your alternative? You make a
reasonable argument that there is some benefit in being able to extend
iso3166 codes, the same way the IETF standard lets you extend ISO
language codes, but I'm not convinced it come up much in real life or if
it does, that you can't just figure it out from other parts of the
address. I don't think there is any standard for such extensions and I
don't think the TRADE WG wants to take on defining such a standard.

> Practially speaking, for iso3166 territorial jurisdictions (TJs), implementors
> will use 3166 code. Realistically, implementors for non-3166 TJs will consult
> the TJ for identifiers.

I would note that all the financial card network protocols I know of get
along fine using UN Country numbers, which are pretty much the same as
iso3166 country codes.

> Eric

Donald

Date: Mon, 10 Jun 2002 11:30:42 -0400
From: Eric Brunner <[email-masked]>
Subject: Re: new ECML v 2 requirements from Nokia
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: 'Eric Brunner' <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]

Donald,

The big issue is jurisdiction, from which the regulatory circumstances and
taxation consequences of a transaction arise.

> I'm not quite so clear on country codes but if you include the codes
> reserved in ISO 3166 but not actually issued, I think you cover the entities
> in the Universal Postal Union.  Can you give an example of a jurisdiction
> not covered by that which would be of any significance in this protocol?

The Navajo Nation is vastly larger than the Vatican State, Monacco, Pitcarn's
Island, the Channel Islands, the Sechyelles, and a dozen Pacific Nations ...
combined. The Pequot Nation is vastly wealthier than some of those also.

To limit the territorial jurisdiction identifiers to the criteria set by the
DIN makes two-byte comparison easy, but it subordinates use to "states".

Tell me how I can use thie protocol if the trading community consists of
financial clearinghouse operating companies located within the soverign
indigenous nations of North America (I already know the answer for soverign
colonial nations).

> This protocol will only be interoperable to the extent that field values are
> well defined. There is nothing wrong with having non-interoperable private
> values and extensions, but I believe we should strive to have an
> interoperable core of values.

We shouldn't use iso3166 unless there really is no alternative. Until last
year you couldn't even find Palestine in 3166.

Practially speaking, for iso3166 territorial jurisdictions (TJs), implementors
will use 3166 code. Realistically, implementors for non-3166 TJs will consult
the TJ for identifiers.

Eric

Content-return: allowed
Date: Mon, 10 Jun 2002 11:01:50 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: RE: new ECML v 2 requirements from Nokia
To: 'Eric Brunner' <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

Hi Eric,

IETF Language Tags have ample provision for extension and registration of
languages not in ISO 639 so I really don't see any problem in defining that
field by reference to RFC 3066. (I was in error in the previous message
referring to RFC 3282. That RFC defines the Content-Language header which
uses language tags. The current definition for Language Tags is in RFC
3066.)

I'm not quite so clear on country codes but if you include the codes
reserved in ISO 3166 but not actually issued, I think you cover the entities
in the Universal Postal Union.  Can you give an example of a jurisdiction
not covered by that which would be of any significance in this protocol?

This protocol will only be interoperable to the extent that field values are
well defined. There is nothing wrong with having non-interoperable private
values and extensions, but I believe we should strive to have an
interoperable core of values.

Thanks,
Donald

-----Original Message-----
From: Eric Brunner [mailto:[email-masked]]
Sent: Monday, June 10, 2002 10:39 AM
To: Donald Eastlake 3rd
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: new ECML v 2 requirements from Nokia

Donald,

I suggest that the references to iso3166 (and iso639) be recommended,
not manditory. There are jurisdictions that don't exist in 3166, and
languages that aren't in 639. Error semantics and local extensibility
are preferable over global uniqueness off of two- or three-alpha codes
that force extension (and error handling) elsewhere.

Eric

Date: Mon, 10 Jun 2002 10:39:08 -0400
From: Eric Brunner <[email-masked]>
Subject: Re: new ECML v 2 requirements from Nokia
To: Donald Eastlake 3rd <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

Donald,

I suggest that the references to iso3166 (and iso639) be recommended,
not manditory. There are jurisdictions that don't exist in 3166, and
languages that aren't in 639. Error semantics and local extensibility
are preferable over global uniqueness off of two- or three-alpha codes
that force extension (and error handling) elsewhere.

Eric

Date: Mon, 10 Jun 2002 09:32:22 -0400 (EDT)
From: Donald Eastlake 3rd <[email-masked]>
Subject: RE: new ECML v 2 requirements from Nokia
To: [email-masked]
Cc: [email-masked], [email-masked]

Since the fields in ECML are all optional (although use in any
particular application can specify that, for that applicaiton, some
fields are mandatory or whatever), adding a few more fields that are
broadly applicable is fine, within reason. But the fields need to be
well specified...

See some of my comments as a working group member below.

Donald
======================================================================
 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]

On Tue, 4 Jun 2002 [email-masked] wrote:

> Date: Tue, 04 Jun 2002 09:16:09 +0300
> From: [email-masked]
> To: [email-masked], [email-masked]
> Subject: RE: new ECML v 2 requirements from Nokia
>
> Hi,
>
> Good point on the loyalty number length. The usage of the ISO standard
> card numbering is a fact. My proposal for longer field comes from the
> fact that I have heard some loyalty schemes to use track 3, for which
> I have no information at all on the contents length. Also I am not
> sure if we want to limit he loyalty number to the comapnies following
> ISO, I do not see any problem in allowing longer lenth if it can be
> used by more services.
>
> Also, as the ISO card numbers are defined numbers, some loyalty
> programs (flight loyalty at least) have also characters in the number
> information. This to me suggests that it is not wise to limit
> ourselves only to the ISO defined 19 character field.

I have a hotel loyalty card that has letters in the "card number" and
does not seem to follow ISO numbering for the numeric part. So I think
that allowing some flexibility here is reasonable.

> - Lauri Piikivi
> --------------------------------------------------------
> Specialist, SW Architecture
> Nokia Mobile Software
>
> [email-masked]
> phone: +358 7180 47045
> mobile:+358 40 559 7045
> --------------------------------------------------------
>
> > -----Original Message-----
> > From: ext Chris Brandt [mailto:[email-masked]]
> > Sent: 03 June, 2002 22:08
> > To: Piikivi Lauri (NMP/Oulu); [email-masked]
> > Subject: RE: new ECML v 2 requirements from Nokia
> >
> > I would argue that the loyalty card number does not need to
> > be longer than 19 digits, simply
> > because a standard credit card magstripe cannot hold much
> > more than 19 digits. In fact many loyalty
> > programs today use ISO standard card numbers.
> >
> > As for the loyalty expiry date, why not have a single field
> > formatted as an XML date (CCYY-MM-DD)?

That would be a great idea if we were starting fresh but there are
already other date fields in ECML v1 and the ECML v2 draft so I think
that following them is probably best.

> > _________________________________________________
> >
> > Christopher Brandt
> > Interfaces Manager
> > Ernex Marketing Technologies
> > Suite 225
> > 4259 Canada Way
> > Burnaby, BC, V5G 1H1
> > Ph:  604-415-1554
> > Cell: 604-728-1537
> > Fx:  604-415-1589
> > [email-masked]
> > www.ernexinc.com
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Monday, June 03, 2002 5:44 AM
> > To: [email-masked]
> > Subject: new ECML v 2 requirements from Nokia
> >
> > NEW ECML v 2 REQUIREMENTS from Nokia
> >
> > Nokia has identified need for new ECML fields, we  would like
> > to see these in ECML version 2. Below
> > is short description on the need for fields and a proposal
> > for the field name, length and usage
> > notes.
> >
> > Nokia among other companies is driving for ticketing usage of
> > mobile terminal in MeT forum
> > www.mobiletransaction.org. In these scenarios a ticket is
> > purchased remotely using ECML, but as an
> > identifier for possible later ticket refunds and for using
> > the mobile device as the access token ,
> > a device unique ID number is given for the ticketing service
> > provider. Thus a new ECML field is
> > needed where the ticketing service provider requests the ID
> > and terminal can respond. Also
> > information on the ID type is given.
> >
> > Ecom_Device_ID
> > length: 70     Note: alphanumeric unique identifier
> > (length=IPv6 space)

Assuming the ID is different for different types, we don't have to worry
about defining them to closely, just reserving enough space. Presumably
they are defined in conjuction with the specification of each type.

> > Ecom_Device_ID_type
> > Required if Device ID used.
> > length: 20     Note: name or brand of deviceID system used

Does there need to be an IANA registry for these? I would think so, for
interoperability, unless we can use an existing registry such as domain
names or Ecom_Payment_Card_Type, but that doesn't seem likely.

If so, this needs to be added to the IANA considerations section.
Also, what should the initially registered values be?

> > Also for remote purchasing, a need for loyalty card
> > information has been identified. Thus in
> > payment situations the user can also tell the commerce site a
> > loyalty card number and receive bonus
> > points etc. It is assumed that the user will select the
> > correct bonus card system, so that the site
> > can advertise that it accepts  "e.g."  a K-shop loyalty card
> > and user will send the correct card if
> > he/she has multiple loyalty cards.
> >
> > Loyalty cards often include expiry date. Loyalty cards may
> > contain credit payment to that shop or
> > chain, therefore the data needed for a loyalty card is
> > similar to payment card data. Systems
> > already hanfle loyalty cards with same data as magnetic
> > stripe payment cards. Small difference is
> > that loyalty card numbers do not seem to have any common
> > standard (as comapred to payment card
> > number, ISO 7812), so longer field is needed.
> >
> > Ecom_Loyalty_Card_Name

I assume this is intended to be the cardholder name? If so, it should
probably have the same 30 character length limit.

> > Ecom_Loyalty_Card_Number
> > Requried minimum data for loyalty usage.
> > length:60         Note: Not purely number, number field may
> > contain also characters (e.g. flight
> > bonus  cards)
> >
> > Ecom_Loyalty_Card_Type
> > lenght:20		Note: longer text field needed due to
> > amount of loyalty systems

See comment above on Ecom_Device_ID_Type.

> > Ecom_Loyalty_Card_Verification

Should this be the same 4 character limit as the payment card
verifiction field?

> > Ecom_Loyalty_Card_ExpDaate_Day
> > Ecom_Loyalty_Card_ExpDate_Month
> > Ecom_Loyalty_Card_ExpDate_Year
> >
> > And a need for generic user data for simple content
> > personlaization has been identified. User can
> > send some generic personal information fo further allow the
> > service to tailor the content for the
> > age and or location of the user.
> >
> > Ecom_UserData_BirthDate_Day
> > lenght: 2
> >
> > Ecom_UserData_BirthDate_Month
> > length: 2
> >
> > Ecom_UserData_BirthDate_Year
> > length: 4
> >
> > Ecom_UserData_Country
> > length:20

Why can't this be an ISO 2 letter ISO Country code as already used in
Ecom_x_Postal_CountryCode for various x?

> > Ecom_UserData_Language
> > length:20

It needs to be specified what format this is. I would recommend IETF
country codes as per RFC 3282, In which case, although most would be
short, you might allow a little more length for odd cases.

> > Ecom_UserData_Gender
> > length:1
> > M(ale)/F(emale)
> >
> > Ecom_UserData_Preferences
> > length:60    Note: This would be free text
> >
> >
> > sincerely,
> > - Lauri Piikivi
> > --------------------------------------------------------
> > Specialist, SW Architecture
> > Nokia Mobile Software
> > [email-masked]
> > phone: +358 7180 47045
> > mobile:+358 40 559 7045
> > --------------------------------------------------------

As chair:

If there isn't much objection and the details of these fields can be
settled, I suggest they be added and we try to get this document out to
the IESG for considertion.

1 July 2002 at 9AM Eastern US Time is the cut off for revised
Internet-Drafts before the Yokohama IETF meeting. While this document
doesn't have to be done by then, I think that is a reasonable goal.

Thanks,
Donald

Content-return: allowed
Date: Fri, 07 Jun 2002 14:34:58 -0400
From: Eastlake III Donald-LDE008 <[email-masked]>
Subject: TRADE Working Group in Yokohama
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_/rpn8FzmuKsvmuUc3LHsaw)
Content-type: text/plain; charset=iso-8859-1

The TRADE WG meeting at the 54th IETF meeting in Yokohama is currently
scheduled for Monday afternoon, July 15th. This is not firm and may change.

People should send me requests for things to be on the agenda.

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_/rpn8FzmuKsvmuUc3LHsaw)
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_/rpn8FzmuKsvmuUc3LHsaw)--

Content-return: allowed
Date: Tue, 04 Jun 2002 06:05:26 -0700
From: Chris Brandt <[email-masked]>
Subject: RE: new ECML v 2 requirements from Nokia
To: "[email-masked]'" <[email-masked]>, Chris Brandt <[email-masked]>, [email-masked]

In our experience (as an electronic loyalty marketing company) we have never used, or even seen
used, track 3. It was brought in to add extra data beyond the card number, more personal stuff like
address and telephone number. But reality is that most magstripe readers currently in service, only
read tracks 1 and 2. And as for alpha numeric card numbers. Any that we have seen have actually
been shorter than 19 character.

In any case, there is probably very little downside to specifying the field be longer. It just
means the client (and/or server) will have to do more expclit checking on the information in the
field. Since, if I'm expecting a 19 digit card number, I can't rely on XML validation to weed out
requests with 22 digit card numbers.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 03, 2002 11:16 PM
To: [email-masked]; [email-masked]
Subject: RE: new ECML v 2 requirements from Nokia

Hi,

Good point on the loyalty number length. The usage of the ISO standard card numbering is a fact. My
proposal for longer field comes from the fact that I have heard some loyalty schemes to use track
3, for which I have no information at all on the contents length. Also I am not sure if we want to
limit he loyalty number to the comapnies following ISO, I do not see any problem in allowing longer
lenth if it can be used by more services. 

Also, as the ISO card numbers are defined numbers, some loyalty programs (flight loyalty at least)
have also characters in the number information. This to me suggests that it is not wise to limit
ourselves only to the ISO defined 19 character field.

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

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

> -----Original Message-----
> From: ext Chris Brandt [mailto:[email-masked]]
> Sent: 03 June, 2002 22:08
> To: Piikivi Lauri (NMP/Oulu); [email-masked]
> Subject: RE: new ECML v 2 requirements from Nokia
> 
> 
> I would argue that the loyalty card number does not need to 
> be longer than 19 digits, simply
> because a standard credit card magstripe cannot hold much 
> more than 19 digits. In fact many loyalty
> programs today use ISO standard card numbers.
> 
> As for the loyalty expiry date, why not have a single field 
> formatted as an XML date (CCYY-MM-DD)?
> 
> _________________________________________________
> 
> Christopher Brandt
> Interfaces Manager
> Ernex Marketing Technologies
> Suite 225
> 4259 Canada Way
> Burnaby, BC, V5G 1H1
> Ph:  604-415-1554
> Cell: 604-728-1537
> Fx:  604-415-1589
> [email-masked]
> www.ernexinc.com
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 5:44 AM
> To: [email-masked]
> Subject: new ECML v 2 requirements from Nokia
> 
> 
> NEW ECML v 2 REQUIREMENTS from Nokia
> 
> Nokia has identified need for new ECML fields, we  would like 
> to see these in ECML version 2. Below
> is short description on the need for fields and a proposal 
> for the field name, length and usage
> notes.
> 
> Nokia among other companies is driving for ticketing usage of 
> mobile terminal in MeT forum
> www.mobiletransaction.org. In these scenarios a ticket is 
> purchased remotely using ECML, but as an
> identifier for possible later ticket refunds and for using 
> the mobile device as the access token ,
> a device unique ID number is given for the ticketing service 
> provider. Thus a new ECML field is
> needed where the ticketing service provider requests the ID 
> and terminal can respond. Also
> information on the ID type is given.
> 
> Ecom_Device_ID       
> length: 70     Note: alphanumeric unique identifier 
> (length=IPv6 space)
> 
> Ecom_Device_ID_type  
> Required if Device ID used.
> length: 20     Note: name or brand of deviceID system used
> 
> Also for remote purchasing, a need for loyalty card 
> information has been identified. Thus in
> payment situations the user can also tell the commerce site a 
> loyalty card number and receive bonus
> points etc. It is assumed that the user will select the 
> correct bonus card system, so that the site
> can advertise that it accepts  "e.g."  a K-shop loyalty card 
> and user will send the correct card if
> he/she has multiple loyalty cards. 
> 
> Loyalty cards often include expiry date. Loyalty cards may 
> contain credit payment to that shop or
> chain, therefore the data needed for a loyalty card is 
> similar to payment card data. Systems
> already hanfle loyalty cards with same data as magnetic 
> stripe payment cards. Small difference is
> that loyalty card numbers do not seem to have any common 
> standard (as comapred to payment card
> number, ISO 7812), so longer field is needed.
> 
> Ecom_Loyalty_Card_Name
>     
> Ecom_Loyalty_Card_Number    
> Requried minimum data for loyalty usage.
> length:60         Note: Not purely number, number field may 
> contain also characters (e.g. flight
> bonus  cards)
> 
> Ecom_Loyalty_Card_Type
> lenght:20		Note: longer text field needed due to 
> amount of loyalty systems
> 
> Ecom_Loyalty_Card_Verification
> 
> Ecom_Loyalty_Card_ExpDaate_Day
> Ecom_Loyalty_Card_ExpDate_Month
> Ecom_Loyalty_Card_ExpDate_Year
> 
> And a need for generic user data for simple content 
> personlaization has been identified. User can
> send some generic personal information fo further allow the 
> service to tailor the content for the
> age and or location of the user.
> 
> Ecom_UserData_BirthDate_Day        
> lenght: 2                
> 
> Ecom_UserData_BirthDate_Month     
> length: 2
> 
> Ecom_UserData_BirthDate_Year       
> length: 4
> 
> Ecom_UserData_Country          
> length:20
> 
> Ecom_UserData_Language       
> length:20
> 
> Ecom_UserData_Gender          
> length:1
> M(ale)/F(emale)
> 
> Ecom_UserData_Preferences   
> length:60    Note: This would be free text 
> 
> 
> sincerely,
> - Lauri Piikivi 
> -------------------------------------------------------- 
> Specialist, SW Architecture 
> Nokia Mobile Software
> [email-masked] 
> phone: +358 7180 47045 
> mobile:+358 40 559 7045 
> -------------------------------------------------------- 
> 

Date: Tue, 04 Jun 2002 09:16:09 +0300
From: [email-masked]
Subject: RE: new ECML v 2 requirements from Nokia
To: [email-masked], [email-masked]
content-class: urn:content-classes:message

Hi,

Good point on the loyalty number length. The usage of the ISO standar=
d card numbering is a fact. My proposal for longer field comes from t=
he fact that I have heard some loyalty schemes to use track 3, for wh=
ich I have no information at all on the contents length. Also I am no=
t sure if we want to limit he loyalty number to the comapnies followi=
ng ISO, I do not see any problem in allowing longer lenth if it can b=
e used by more services.=20

Also, as the ISO card numbers are defined numbers, some loyalty progr=
ams (flight loyalty at least) have also characters in the number info=
rmation. This to me suggests that it is not wise to limit ourselves o=
nly to the ISO defined 19 character field.

- 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

> -----Original Message-----
> From: ext Chris Brandt [mailto:[email-masked]]
> Sent: 03 June, 2002 22:08
> To: Piikivi Lauri (NMP/Oulu); [email-masked]
> Subject: RE: new ECML v 2 requirements from Nokia
>=20
>=20
> I would argue that the loyalty card number does not need to=20
> be longer than 19 digits, simply
> because a standard credit card magstripe cannot hold much=20
> more than 19 digits. In fact many loyalty
> programs today use ISO standard card numbers.
>=20
> As for the loyalty expiry date, why not have a single field=20
> formatted as an XML date (CCYY-MM-DD)?
>=20
> _________________________________________________
>=20
> Christopher Brandt
> Interfaces Manager
> Ernex Marketing Technologies
> Suite 225
> 4259 Canada Way
> Burnaby, BC, V5G 1H1
> Ph:  604-415-1554
> Cell: 604-728-1537
> Fx:  604-415-1589
> [email-masked]
> www.ernexinc.com
>=20
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, June 03, 2002 5:44 AM
> To: [email-masked]
> Subject: new ECML v 2 requirements from Nokia
>=20
>=20
> NEW ECML v 2 REQUIREMENTS from Nokia
>=20
> Nokia has identified need for new ECML fields, we  would like=20
> to see these in ECML version 2. Below
> is short description on the need for fields and a proposal=20
> for the field name, length and usage
> notes.
>=20
> Nokia among other companies is driving for ticketing usage of=20
> mobile terminal in MeT forum
> www.mobiletransaction.org. In these scenarios a ticket is=20
> purchased remotely using ECML, but as an
> identifier for possible later ticket refunds and for using=20
> the mobile device as the access token ,
> a device unique ID number is given for the ticketing service=20
> provider. Thus a new ECML field is
> needed where the ticketing service provider requests the ID=20
> and terminal can respond. Also
> information on the ID type is given.
>=20
> Ecom_Device_ID      =20
> length: 70     Note: alphanumeric unique identifier=20
> (length=3DIPv6 space)
>=20
> Ecom_Device_ID_type =20
> Required if Device ID used.
> length: 20     Note: name or brand of deviceID system used
>=20
> Also for remote purchasing, a need for loyalty card=20
> information has been identified. Thus in
> payment situations the user can also tell the commerce site a=20
> loyalty card number and receive bonus
> points etc. It is assumed that the user will select the=20
> correct bonus card system, so that the site
> can advertise that it accepts  "e.g."  a K-shop loyalty card=20
> and user will send the correct card if
> he/she has multiple loyalty cards.=20
>=20
> Loyalty cards often include expiry date. Loyalty cards may=20
> contain credit payment to that shop or
> chain, therefore the data needed for a loyalty card is=20
> similar to payment card data. Systems
> already hanfle loyalty cards with same data as magnetic=20
> stripe payment cards. Small difference is
> that loyalty card numbers do not seem to have any common=20
> standard (as comapred to payment card
> number, ISO 7812), so longer field is needed.
>=20
> Ecom_Loyalty_Card_Name
>    =20
> Ecom_Loyalty_Card_Number   =20
> Requried minimum data for loyalty usage.
> length:60         Note: Not purely number, number field may=20
> contain also characters (e.g. flight
> bonus  cards)
>=20
> Ecom_Loyalty_Card_Type
> lenght:20=09=09Note: longer text field needed due to=20
> amount of loyalty systems
>=20
> Ecom_Loyalty_Card_Verification
>=20
> Ecom_Loyalty_Card_ExpDaate_Day
> Ecom_Loyalty_Card_ExpDate_Month
> Ecom_Loyalty_Card_ExpDate_Year
>=20
> And a need for generic user data for simple content=20
> personlaization has been identified. User can
> send some generic personal information fo further allow the=20
> service to tailor the content for the
> age and or location of the user.
>=20
> Ecom_UserData_BirthDate_Day       =20
> lenght: 2               =20
>=20
> Ecom_UserData_BirthDate_Month    =20
> length: 2
>=20
> Ecom_UserData_BirthDate_Year      =20
> length: 4
>=20
> Ecom_UserData_Country         =20
> length:20
>=20
> Ecom_UserData_Language      =20
> length:20
>=20
> Ecom_UserData_Gender         =20
> length:1
> M(ale)/F(emale)
>=20
> Ecom_UserData_Preferences  =20
> length:60    Note: This would be free text=20
>=20
>=20
> sincerely,
> - 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
>=20

Content-return: allowed
Date: Mon, 03 Jun 2002 12:07:39 -0700
From: Chris Brandt <[email-masked]>
Subject: RE: new ECML v 2 requirements from Nokia
To: "[email-masked]'" <[email-masked]>, [email-masked]

I would argue that the loyalty card number does not need to be longer than 19 digits, simply
because a standard credit card magstripe cannot hold much more than 19 digits. In fact many loyalty
programs today use ISO standard card numbers.

As for the loyalty expiry date, why not have a single field formatted as an XML date (CCYY-MM-DD)?

_________________________________________________

Christopher Brandt
Interfaces Manager
Ernex Marketing Technologies
Suite 225
4259 Canada Way
Burnaby, BC, V5G 1H1
Ph:  604-415-1554
Cell: 604-728-1537
Fx:  604-415-1589
[email-masked]
www.ernexinc.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 03, 2002 5:44 AM
To: [email-masked]
Subject: new ECML v 2 requirements from Nokia

NEW ECML v 2 REQUIREMENTS from Nokia

Nokia has identified need for new ECML fields, we  would like to see these in ECML version 2. Below
is short description on the need for fields and a proposal for the field name, length and usage
notes.

Nokia among other companies is driving for ticketing usage of mobile terminal in MeT forum
www.mobiletransaction.org. In these scenarios a ticket is purchased remotely using ECML, but as an
identifier for possible later ticket refunds and for using the mobile device as the access token ,
a device unique ID number is given for the ticketing service provider. Thus a new ECML field is
needed where the ticketing service provider requests the ID and terminal can respond. Also
information on the ID type is given.

Ecom_Device_ID       
length: 70     Note: alphanumeric unique identifier (length=IPv6 space)

Ecom_Device_ID_type  
Required if Device ID used.
length: 20     Note: name or brand of deviceID system used

Also for remote purchasing, a need for loyalty card information has been identified. Thus in
payment situations the user can also tell the commerce site a loyalty card number and receive bonus
points etc. It is assumed that the user will select the correct bonus card system, so that the site
can advertise that it accepts  "e.g."  a K-shop loyalty card and user will send the correct card if
he/she has multiple loyalty cards. 

Loyalty cards often include expiry date. Loyalty cards may contain credit payment to that shop or
chain, therefore the data needed for a loyalty card is similar to payment card data. Systems
already hanfle loyalty cards with same data as magnetic stripe payment cards. Small difference is
that loyalty card numbers do not seem to have any common standard (as comapred to payment card
number, ISO 7812), so longer field is needed.

Ecom_Loyalty_Card_Name
    
Ecom_Loyalty_Card_Number    
Requried minimum data for loyalty usage.
length:60         Note: Not purely number, number field may contain also characters (e.g. flight
bonus  cards)

Ecom_Loyalty_Card_Type
lenght:20		Note: longer text field needed due to amount of loyalty systems

Ecom_Loyalty_Card_Verification

Ecom_Loyalty_Card_ExpDaate_Day
Ecom_Loyalty_Card_ExpDate_Month
Ecom_Loyalty_Card_ExpDate_Year

And a need for generic user data for simple content personlaization has been identified. User can
send some generic personal information fo further allow the service to tailor the content for the
age and or location of the user.

Ecom_UserData_BirthDate_Day        
lenght: 2                

Ecom_UserData_BirthDate_Month     
length: 2

Ecom_UserData_BirthDate_Year       
length: 4

Ecom_UserData_Country          
length:20

Ecom_UserData_Language       
length:20

Ecom_UserData_Gender          
length:1
M(ale)/F(emale)

Ecom_UserData_Preferences   
length:60    Note: This would be free text 

sincerely,
- Lauri Piikivi 
-------------------------------------------------------- 
Specialist, SW Architecture 
Nokia Mobile Software
[email-masked] 
phone: +358 7180 47045 
mobile:+358 40 559 7045 
-------------------------------------------------------- 

Date: Mon, 03 Jun 2002 15:43:34 +0300
From: [email-masked]
Subject: new ECML v 2 requirements from Nokia
To: [email-masked]
content-class: urn:content-classes:message

NEW ECML v 2 REQUIREMENTS from Nokia

Nokia has identified need for new ECML fields, we  would like to see =
these in ECML version 2. Below is short description on the need for f=
ields and a proposal for the field name, length and usage notes.

Nokia among other companies is driving for ticketing usage of mobile =
terminal in MeT forum www.mobiletransaction.org. In these scenarios a=
 ticket is purchased remotely using ECML, but as an identifier for po=
ssible later ticket refunds and for using the mobile device as the ac=
cess token , a device unique ID number is given for the ticketing ser=
vice provider. Thus a new ECML field is needed where the ticketing se=
rvice provider requests the ID and terminal can respond. Also informa=
tion on the ID type is given.

Ecom_Device_ID      =20
length: 70     Note: alphanumeric unique identifier (length=3DIPv6 sp=
ace)

Ecom_Device_ID_type =20
Required if Device ID used.
length: 20     Note: name or brand of deviceID system used

Also for remote purchasing, a need for loyalty card information has b=
een identified. Thus in payment situations the user can also tell the=
 commerce site a loyalty card number and receive bonus points etc. It=
 is assumed that the user will select the correct bonus card system, =
so that the site can advertise that it accepts  "e.g."  a K-shop loya=
lty card and user will send the correct card if he/she has multiple l=
oyalty cards.=20

Loyalty cards often include expiry date. Loyalty cards may contain cr=
edit payment to that shop or chain, therefore the data needed for a l=
oyalty card is similar to payment card data. Systems already hanfle l=
oyalty cards with same data as magnetic stripe payment cards. Small d=
ifference is that loyalty card numbers do not seem to have any common=
 standard (as comapred to payment card number, ISO 7812), so longer f=
ield is needed.

Ecom_Loyalty_Card_Name
   =20
Ecom_Loyalty_Card_Number   =20
Requried minimum data for loyalty usage.
length:60         Note: Not purely number, number field may contain a=
lso characters (e.g. flight bonus  cards)

Ecom_Loyalty_Card_Type
lenght:20=09=09Note: longer text field needed due to amount of loyalt=
y systems

Ecom_Loyalty_Card_Verification

Ecom_Loyalty_Card_ExpDaate_Day
Ecom_Loyalty_Card_ExpDate_Month
Ecom_Loyalty_Card_ExpDate_Year

And a need for generic user data for simple content personlaization h=
as been identified. User can send some generic personal information f=
o further allow the service to tailor the content for the age and or =
location of the user.

Ecom_UserData_BirthDate_Day       =20
lenght: 2               =20

Ecom_UserData_BirthDate_Month    =20
length: 2

Ecom_UserData_BirthDate_Year      =20
length: 4

Ecom_UserData_Country         =20
length:20

Ecom_UserData_Language      =20
length:20

Ecom_UserData_Gender         =20
length:1
M(ale)/F(emale)

Ecom_UserData_Preferences  =20
length:60    Note: This would be free text=20

sincerely,
- 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