Comments to ECML v2 draft v4 (july 2002)

[lauri.piikivi@nokia.com]

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