Subject: RE: ConsumerDeliveryId

From: "Smith, Chris " <[email-masked]>
Date: Wed, 28 Jul 1999 09:52:57 -0400

I had some problems understanding the original request from
Andrew. Was this info actually in 6.12, not 6.2?

Either way, now I think I see what we're after here...

Isn't ConsumerDeliveryId the same in concept as the ConsumerPaymentId?

As such, the error would appear to be that the ConsumerDeliveryId must
appear on all items that contain and delivery Packaged Content. This
means that it should be added as an attribute to DeliveryData.

In use, the Consumer role can create a unique-to-themselves ID for each
expected delivery. This ID is attached to the ConsumerDeliveryId on
the Delivery element inside the DeliveryReqBlk.

The only error is that the DeliveryNote inside the DeliveryRespBlk should
ALSO have ConsumerDeliveryId, so that the Consumer Role can link the inbound
DeliveryNote to the original outbound Delivery.

...chris

------------------------------------------------------------
 Chris Smith                                +1.416.348.6090
 Royal Bank                       [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: July 27, 1999 10:41 PM
> To: [email-masked]; [email-masked]
> Subject: RE: ConsumerDeliveryId
> 
> 
> Andrew, I've been putting this one off since to handle it properly it
> requires a new component which is generated by the Consumer 
> that contains
> only this item. But on the other hand, it could be important, 
> particularly
> if the sender of the Delivery Request is a system (e.g. a B2B 
> system) rather
> than real person to be able to identify the message that is 
> being returned.
> 
> Detailed changes below.
> 
> David
> 
> 1. Define new Consumer Delivery Data Component ...
> 
> <!-- CONSUMER DELIVERY DATA COMPONENT -->
> <!ELEMENT ConsumerDeliveryData EMPTY >
> <!ATTLIST ConsumerDeliveryData
>  ID                 ID      #REQUIRED
>  ConsumerDeliveryId CDATA   #REQUIRED >
> 
> 2. Remove ConsumerDeliveryId from the Delivery Component. Now 
> defined as ...
> 
> <!-- DELIVERY COMPONENT -->
> <!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
> <!ATTLIST Delivery
>  ID                 ID      #REQUIRED
>  xml:lang           NMTOKEN #REQUIRED
>  DelivExch          (True | False) #REQUIRED
>  DelivAndPayResp    (True | False) #REQUIRED
>  ActionOrgRef       NMTOKEN #IMPLIED >
> 
> 3. Add optional ConsumerDeliveryData component to Delivery 
> Request Block as
> follows ...
> 
> <!-- DELIVERY REQUEST BLOCK -->
> <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
>      ConsumerDeliveryData?, TradingRoleData*) >
> <!ATTLIST DeliveryReqBlk
>  ID                 ID      #REQUIRED >
> 
> 4. Changed spec as follows:
> 
> - removed description of ConsumerDeliveryId from the Delivery 
> Component
> - added section to describe ConsumerDeliveryData Component 
> with defintion as
> above
> - added description of use of ConsumerDeliveryData Component 
> in a Delivery
> Request Block
> - included signing of the ConsumerDeliveryData Component by 
> the Delivery
> Response Signature if present.
> 
> 
> 
> -----Original Message-----
> From: Andrew Drapp [mailto:[email-masked]]
> Sent: Wednesday, June 16, 1999 8:00 PM
> To: 'Ietf Trade WG'
> Subject: ConsumerDeliveryId
> 
> 
> 
> 
> In section 6.2, the ConsumerDeliveryId is 
> described as follows:
> 
> ---
> An identifier specified by the Consumer which, 
> if returned by the Delivery Handler in another
> Delivery Component, or by other means, will
> enable the Consumer to identify which Delivery
> is being referred to. 
> ---
> 
> This is a bit confusing.  The first time the
> ConsumerDeliveryId is used is in the Offer Response
> Block, so I assume that it is defined by the
> Merchant.  What exactly is meant by "specified"?
> Would replacing "specified" with "used" clarify
> or change the meaning?
> 
> Furthermore, should this Id be unique within
> the IOTP transaction, or globally unique?
> 
> Regards,
> 
> Andrew
> 
> --
> Andrew Drapp
> [email-masked]
> Systems Development Laboratory, Hitachi Ltd.
> Ozenji 1099, Asao, Kawasaki, 215-0013 JAPAN
> TEL:+81-44-966-9111   FAX:+81-44-966-1796
> PGP Fingerprint: 84D8 3D19 018E 9385 6581  0081 C89C D2AD F06A 565F
> 
> --------------------------------------------------------------
> ---------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or 
> "unsubscribe" in the
> body to: [email-masked]
> 
> **************************************************************
> ********************************
> 
> This Email and any attached files are confidential and may 
> also be privileged. 
> If you are not the intended recipient, please notify the 
> postmaster using email 
> address [email-masked] or call +44 171 557 5000 and 
> ask for the 
> IT Helpdesk.  You should not copy this email and any attached 
> files, use them 
> for any purpose or disclose the contents to any other person; 
> all copies of the 
> Email and associated files in your possession should be destroyed.
> 
> Mondex International Limited
> 47-53 Cannon Street
> London EC4M 5SQ
> United Kingdom
> Registered No: 3122085, England
> 
> Phone:          +44 171 557 5000
> Fax:            +44 171 557 5200
> Email:          [email-masked]
> WebSite:        http://www.mondexinternational.com
> 
> **************************************************************
> *******************************
> --------------------------------------------------------------
> ---------
> Message addressed to: [email-masked]
> Archive available at: http://www.elistx.com/archives/ietf-trade/
> To (un)subscribe send a message with "subscribe" or 
> "unsubscribe" in the
> body to: [email-masked]
>