headers
lauri.piikivi | 3 Jun 14:43
Picon

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Brandt | 3 Jun 21:07

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
chris.brandt <at> ernexinc.com
www.ernexinc.com

-----Original Message-----
From: lauri.piikivi <at> nokia.com [mailto:lauri.piikivi <at> nokia.com]
Sent: Monday, June 03, 2002 5:44 AM
To: ietf-trade <at> lists.elistx.com
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
lauri.piikivi | 4 Jun 08:16
Picon

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

lauri.piikivi <at> nokia.com 
phone: +358 7180 47045 
mobile:+358 40 559 7045 
-------------------------------------------------------- 

> -----Original Message-----
> From: ext Chris Brandt [mailto:Chris.Brandt <at> ernexinc.com]
> Sent: 03 June, 2002 22:08
> To: Piikivi Lauri (NMP/Oulu); ietf-trade <at> lists.elistx.com
> Subject: RE: new ECML v 2 requirements from Nokia
> 
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Brandt | 4 Jun 15:05

RE: new ECML v 2 requirements from Nokia

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: lauri.piikivi <at> nokia.com [mailto:lauri.piikivi <at> nokia.com]
Sent: Monday, June 03, 2002 11:16 PM
To: Chris.Brandt <at> ernexinc.com; ietf-trade <at> lists.elistx.com
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eastlake III Donald-LDE008 | 7 Jun 20:34
Favicon

TRADE Working Group in Yokohama

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
Attachment (Eastlake Donald-LDE008.vcf): application/octet-stream, 211 bytes
Permalink | Reply | 0 comments |
headers
Donald Eastlake 3rd | 10 Jun 15:32

RE: new ECML v 2 requirements from Nokia

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                       dee3 <at> torque.pothole.com
 155 Beaver Street              +1-508-634-2066(h) +1-508-851-8280(w)
 Milford, MA 01757 USA                   Donald.Eastlake <at> motorola.com

On Tue, 4 Jun 2002 lauri.piikivi <at> nokia.com wrote:

> Date: Tue, 04 Jun 2002 09:16:09 +0300
> From: lauri.piikivi <at> nokia.com
> To: Chris.Brandt <at> ernexinc.com, ietf-trade <at> lists.elistx.com
> 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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Brunner | 10 Jun 16:39
Picon
Picon
Favicon

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
Permalink | Reply | 0 comments |
headers
Eastlake III Donald-LDE008 | 10 Jun 17:01
Favicon

RE: new ECML v 2 requirements from Nokia

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:brunner <at> world.std.com]
Sent: Monday, June 10, 2002 10:39 AM
To: Donald Eastlake 3rd
Cc: lauri.piikivi <at> nokia.com; Chris.Brandt <at> ernexinc.com;
ietf-trade <at> lists.elistx.com; brunner <at> world.std.com
Subject: Re: new ECML v 2 requirements from Nokia
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eric Brunner | 10 Jun 17:30
Picon
Picon
Favicon

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

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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Donald Eastlake 3rd | 11 Jun 05:35

Re: new ECML v 2 requirements from Nokia

Hi,

On Mon, 10 Jun 2002, Eric Brunner wrote:

> Date: Mon, 10 Jun 2002 11:30:42 -0400
> From: Eric Brunner <brunner <at> world.std.com>
> To: Eastlake III Donald-LDE008 <Donald.Eastlake <at> motorola.com>
> Cc: 'Eric Brunner' <brunner <at> world.std.com>, lauri.piikivi <at> nokia.com,
>      Chris.Brandt <at> ernexinc.com, ietf-trade <at> lists.elistx.com,
>      brunner <at> world.std.com
> 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"
(Continue reading)

Permalink | Reply | 2 comments |

Gmane