Subject: new ECML v 2 requirements from Nokia

From: [email-masked]
Date: Mon, 03 Jun 2002 15:43:34 +0300

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

---

From: Chris Brandt <[email-masked]>
Date: Mon, 03 Jun 2002 12:07:39 -0700

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

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       

Ecom_Device_ID_type  

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

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_Country          
length:20

Ecom_UserData_Language       
length:20

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

sincerely,
- Lauri Piikivi

---

From: Chris Brandt <[email-masked]>
Date: Tue, 04 Jun 2002 06:05:26 -0700

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 

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

> 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
> 
> 
> because a standard credit card magstripe cannot hold much 
> more than 19 digits. In fact many loyalty
> points etc. It is assumed that the user will select the 
> correct bonus card system, so that the site
> already hanfle loyalty cards with same data as magnetic 
> stripe payment cards. Small difference is
> And a need for generic user data for simple content 
> personlaization has been identified. User can

---

From: Ronald Duncan <[email-masked]>
Date: Tue, 11 Jun 2002 21:20:09 +0100

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

---

From: [email-masked]
Date: Wed, 12 Jun 2002 09:26:23 +0300

Hello all,

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

> 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
> 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.

> 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. 

> 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