Subject: ECML: clear field definitions appreciated

From: [email-masked]
Date: Tue, 06 Mar 2001 13:11:14 +0200

Hi,
Old ECML fields were self-explanatory, so they could be explained with a few
foot notes but the new fields require clear definitions, or otherwise the
spec looses its main aim. 

One requirement for the specification work could be that 
a)fields are well-defined in detail for any party to use or 
b)it is explicitly said that this is proprietary field and you can use it as
you like. So if we want to support proprietary work, that's also fine, but
let's do it openly then so that the whole point of spec is not lost.

The fields that in my opinion do not fullfil the above requirements at all
are
1) Ecomm_Payment_Card_Protocol (some values still unclear, although Donald
Eastlake has been admirably trying to get some answers), and 

2) Ecomm_Transaction_Signature field (Ecomm_Transaction_Signature) where the
footnote tells that 
"(31) The signature of the encoded certificate.  This is usually a hidden
field."
Huh? What does this mean?

3) Ones that are promised to be defined later :-)  We will hear about these
more soon I hope.

Best Regards
Mia Lahteenmaki

---

From: "Lewis, Tony" <[email-masked]>
Date: Tue, 06 Mar 2001 08:50:43 -0800

On Tuesday, March 06, 2001 3:11 AM, Mia Lahteenmaki wrote:

> The fields that in my opinion do not fullfil the above requirements at 
> all are 1) Ecomm_Payment_Card_Protocol (some values still unclear, 
> although Donald Eastlake has been admirably trying to get some answers), 

I agree that the fields need to be clearly defined. However, on this
particular field, the specification to allow new values for the field to be
created easily. When new payment protocols are created, it should be easy to
add the protocol so that the creators feel comfortable using IOTP. Perhaps
it is just a matter of creating a registrar for the values.
_________________________________________________________________
Tony Lewis ([email-masked])
Chief Systems Architect, Internet Commerce
Visa International Service Association

---

From: [email-masked]
Date: Wed, 07 Mar 2001 19:14:05 +0200

> On Tuesday 06. March 2001 18:51, Lewis, Tony wrote: 
> 

Good point. I was being unclear. 
I agree Tony that adding new protocols to the 
list should be easy. My intention on the particular 
field was that when introducing a new item value for 
the protocol field we can give 
a)a pointer to the protocol spec or 
b) say that this is a proprietary protocol that 
is not public and it is used by xxx systems. 

In another words, the protocol names on the list must 
unambiquously reference to one protocol. 

Like 'set' is for SET protocol and in the ECML spec a 
reference to the SET specs can be given. 
Both parties know exactly what it means. Merchant can 
create a SET wakeup to start the process. 

Now there exist "protocol names" already in the list 
that do not have unambiguous meaning, like "simcard" 
and "phoneid". These values do not define any one protocol 
or at least we have no reference to such protocols. 
So if merchant receives these values from the wallet 
what he should do next?  

I assume that the underlying assumption about the mobile
world has been that the customer is able to shop only in 
a closed operator network where both the customer and 
the merchant necessarily have contracts with the operator. 
Inside this network the meaning of these protocol names 
would then be unabiquously defined and everything would 
work fine.
With mobile access to internet e.g., via WAP this is not 
however true. 

Best Regards,
Mia

---

From: "Lewis, Tony" <[email-masked]>
Date: Wed, 07 Mar 2001 11:53:39 -0800

> unambiquously reference to one protocol. 

I agree wholeheartedly.
 
> create a SET wakeup to start the process. 

Perhaps it would be better to use something like
http://www.setco.org/set/v1.0 instead of "set".
 
> So if merchant receives these values from the wallet 

We should get rid of the names that don't correlate to a specific protocol.