RE: new ECML v 2 requirements from Nokia

[lauri.piikivi@nokia.com]

Hello all,

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

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

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

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

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

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