RE: new ECML v 2 requirements

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

Since there doesn't seem to have been any objection to these fields, just
discussion on their format, the draft will be updated to add them with some
specification and we can further refine that, if needed.

Thanks,
Donald

-----Original Message-----
From: lauri.piikivi@nokia.com [mailto:lauri.piikivi@nokia.com]
Sent: Wednesday, June 12, 2002 2:26 AM
To: ietf-trade@lists.elistx.com
Subject: RE: new ECML v 2 requirements from Nokia

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