RE: new ECML v 2 requirements from Nokia

[Donald Eastlake 3rd <dee3@torque.pothole.com>]

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

On Tue, 4 Jun 2002 lauri.piikivi@nokia.com wrote:

> Date: Tue, 04 Jun 2002 09:16:09 +0300
> From: lauri.piikivi@nokia.com
> To: Chris.Brandt@ernexinc.com, ietf-trade@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.

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
>
> lauri.piikivi@nokia.com
> phone: +358 7180 47045
> mobile:+358 40 559 7045
> --------------------------------------------------------
>
> > -----Original Message-----
> > From: ext Chris Brandt [mailto:Chris.Brandt@ernexinc.com]
> > Sent: 03 June, 2002 22:08
> > To: Piikivi Lauri (NMP/Oulu); ietf-trade@lists.elistx.com
> > 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
> > chris.brandt@ernexinc.com
> > www.ernexinc.com
> >
> > -----Original Message-----
> > From: lauri.piikivi@nokia.com [mailto:lauri.piikivi@nokia.com]
> > Sent: Monday, June 03, 2002 5:44 AM
> > To: ietf-trade@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
> > 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
> > lauri.piikivi@nokia.com
> > 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