Eastlake III Donald-LDE008 | 5 Aug 20:42 2002

Use of Ecom_SchemaVersion in ECML

A question as arisen about Ecom_SchemaVersion, in particular as to whether
it is intended for merchant to client or client to merchant communication.

In ECML v1, this sort of thing is a bit messy. It was permitted for the
merchant to communicate to the client by putting a value in a field. This
might be just to tell the client something or to provide a default value to
be returned to the merchant if not changed by the client. I don't think
there were any cases of serious conflict between these two uses.

In ECML v2, there is the Mode attribute to clarify this. If it is set to
Assert, then you know the field value is being sent to recipient. If it is
set to Query, then you know the recipient is being asked to insert a value
and any value provided to the recipient is a default.

Getting back to the Ecom_SchemaVersion field, these general considerations
don't seem to clarify it much.  I think if a value is provided from the
merchant, it means the level of answer the merchant is expecting. In v1, the
client is expected to change it to the level supported by the client. In v2,
this is only true if the Mode is absent or Query.

Any comments?

Donald

Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax)
Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA

Attachment (Eastlake Donald-LDE008.vcf): application/octet-stream, 289 bytes
Eastlake III Donald-LDE008 | 5 Aug 20:42 2002

Use of Ecom_SchemaVersion in ECML

A question as arisen about Ecom_SchemaVersion, in particular as to whether
it is intended for merchant to client or client to merchant communication.

In ECML v1, this sort of thing is a bit messy. It was permitted for the
merchant to communicate to the client by putting a value in a field. This
might be just to tell the client something or to provide a default value to
be returned to the merchant if not changed by the client. I don't think
there were any cases of serious conflict between these two uses.

In ECML v2, there is the Mode attribute to clarify this. If it is set to
Assert, then you know the field value is being sent to recipient. If it is
set to Query, then you know the recipient is being asked to insert a value
and any value provided to the recipient is a default.

Getting back to the Ecom_SchemaVersion field, these general considerations
don't seem to clarify it much.  I think if a value is provided from the
merchant, it means the level of answer the merchant is expecting. In v1, the
client is expected to change it to the level supported by the client. In v2,
this is only true if the Mode is absent or Query.

Any comments?

Donald

Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax)
Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA

Attachment (Eastlake Donald-LDE008.vcf): application/octet-stream, 289 bytes
lauri.piikivi | 8 Aug 10:20 2002
Picon

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

(Continue reading)

lauri.piikivi | 8 Aug 10:20 2002
Picon

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

(Continue reading)

rfc-editor | 14 Aug 20:38 2002

RFC 3354 on Internet Open Trading Protocol Version 2 Requirements


A new Request for Comments is now available in online RFC libraries.

        RFC 3354

        Title:	    Internet Open Trading Protocol Version 2
                    Requirements 
        Author(s):  D. Eastlake, III
        Status:	    Informational
	Date:       August 2002
        Mailbox:    Donald.Eastlake <at> motorola.com
        Pages:      6
        Characters: 9671
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-trade-iotp2-rep-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3354.txt

This document gives requirements for the Internet Open Trading
Protocol (IOTP) Version 2 by describing design principles and scope
and dividing features into those which will, may, or will not be
included.

Version 2 of the IOTP will extend the interoperable framework for
Internet commerce capabilities of Version 1 while replacing the XML
messaging and digital signature part of IOTP v1 with standards based
mechanisms.

This document is a product of the Open Trading Protocol Working Group
(Continue reading)

Ko Fujimura | 15 Aug 12:34 2002
Picon

Re: Unique identifier of the Voucher Component

Donald,

I'm sorry for not proposing the resolution for the issue on 
ID attribute of XML Voucher for a long time:

http://lists.elistx.com/archives/ietf-trade/200206/msg00021.html

After rethinking this issue, I can't see the requirements on 
having the ID attribute WITHIN a Voucher Component although the 
ID generation rule itself might be useful.

So, I would like propose not to introduce the ID attribute, i.e.,
keep the current spec as it is.

Alternately, it may be a good idea to add some description on 
how to generate the identifier of Voucher Component in the VTS-API 
specification (5.8.1 getIdentifier). How do you think?

Thank you

Ko

rfc-editor | 15 Aug 18:12 2002

Corrected: RFC 3354 on Internet Open Trading Protocol Version 2 Requirements


A new Request for Comments is now available in online RFC libraries.

        RFC 3354

        Title:	    Internet Open Trading Protocol Version 2
                    Requirements 
        Author(s):  D. Eastlake, III
        Status:	    Informational
	Date:       August 2002
        Mailbox:    Donald.Eastlake <at> motorola.com
        Pages:      6
        Characters: 9671
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-trade-iotp2-req-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3354.txt

This document gives requirements for the Internet Open Trading
Protocol (IOTP) Version 2 by describing design principles and scope
and dividing features into those which will, may, or will not be
included.

Version 2 of the IOTP will extend the interoperable framework for
Internet commerce capabilities of Version 1 while replacing the XML
messaging and digital signature part of IOTP v1 with standards based
mechanisms.

This document is a product of the Open Trading Protocol Working Group
(Continue reading)

Eastlake III Donald-LDE008 | 15 Aug 23:07 2002

RE: Unique identifier of the Voucher Component

Ko,

Yes, since there have been no comments opposing your view and some support
for it, we won't add an ID attribute in the Voucher Component.

I agree that adding some text on how to generate a unique identifier is a
good idea.

Thanks,
Donald

-----Original Message-----
From: Ko Fujimura [mailto:fujimura <at> isl.ntt.co.jp]
Sent: Thursday, August 15, 2002 6:35 AM
To: Donald Eastlake 3rd
Cc: iang <at> systemics.com; ietf-trade <at> lists.elistx.com; Masayuki TERADA; Ko
Fujimura
Subject: Re: Unique identifier of the Voucher Component

Donald,

I'm sorry for not proposing the resolution for the issue on 
ID attribute of XML Voucher for a long time:

http://lists.elistx.com/archives/ietf-trade/200206/msg00021.html

After rethinking this issue, I can't see the requirements on 
having the ID attribute WITHIN a Voucher Component although the 
ID generation rule itself might be useful.

(Continue reading)

Eastlake III Donald-LDE008 | 21 Aug 22:19 2002

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

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 <at> nokia.com [mailto:lauri.piikivi <at> nokia.com]
Sent: Thursday, August 08, 2002 4:20 AM
To: ietf-trade <at> 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
(Continue reading)

Eastlake III Donald-LDE008 | 21 Aug 22:19 2002

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

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 <at> nokia.com [mailto:lauri.piikivi <at> nokia.com]
Sent: Thursday, August 08, 2002 4:20 AM
To: ietf-trade <at> 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
(Continue reading)


Gmane