RE: Comments to ECML v2 draft v4 (July 2002)

[Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>]

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

Donald

-----Original Message-----
From: lauri.piikivi@nokia.com [mailto:lauri.piikivi@nokia.com]
Sent: Thursday, August 08, 2002 4:20 AM
To: ietf-trade@lists.elistx.com
Subject: Comments to ECML v2 draft v4 (july 2002)

Hi alls,

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

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

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

LOYALTY CARD

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

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

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

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

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

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

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

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