changing the shipping address (was RE: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt)

[Andras Varga <[e-mail]>]

David,
Thanks for your comments. I added some more details and problems we see...

> > Comment:
> > Authentication Exchange can be used to communicate trading 
> > role info between trading roles. For example, the Delivery 
> > Handler can authenticate the Consumer to obtain the shipping 
> > address. A potential problem is that Authentication is initiated 
> > by the Delivery Handler not the Consumer, so I believe 
> > currently there is no way for the 
> > Consumer to tell a changed shipping address to the Delivery Handler 
> > unless the Delivery Handler explicitly asks for it in an 
> > Authentication Reqeuest. Opinions?
> > ## This has been already discussed. See
> > http://www.elistx.com/archives/ietf-trade/199908/msg00035.html##
> 
> FYI, we figured out another way to request shipping to a 
> different address from the Delivery Handler (by means of a new critial 
> element). If someone is interested please write.
>
> && Yes. But changing the shipping address MUST be treated 
> with care as it can mean that the wrong tax is being collected. 
> For example in the US goods bought and shipped within the same 
> state must include sales tax. Goods that are shipped out of state 
> do not (although technically the purchases should report and 
> pay the tax due). So, if the Delivery Handler changes the address
> then it could result in the Merchant being liable for additional 
> tax that he has not received payment for.@@

Good point. According to our idea, the Delivery Hander would examine 
if the address change can be carried out without violating the original 
offer (i.e. the taxing and the shipping cost is the same, etc.). 
If the address change cannot be carried out (or the Delivery Handler
does not support/is not authorized to change the address), 
the Delivery Handler would send back a status with business error 
and an appropriate status description. The Consumer could then retry
the Delivery Request with another address or with keeping the original
address.

There are minor problems with this however. All Delivery Competion 
Codes [7.16.3] say that "Recovery is not possible.", so with the 
current IOTP implementation the Consumer could not retry.

Another problem is if the Delivery Handler does not recognize
the extension to the Delivery Request. Because the element is critical,
this is a technical [4.1] error and the Consumer cannot retry with
another, "plain" Delivery Request. 
OTOH if the extension is non-critical, the Consumer won't know
where the goods are going to be shipped eventually.

[I feel this a sign of a more general problem with extensions.
If the extension is critical it causes technical error and the 
transaction must fail, ie. the trading role sending the message
in error has no possibility to fix the problem by sending a
revised message. OTOH if the extension is non-critical, the 
sender trading role won't know whether the info carried in the
extensions was taken into account. But maybe I'm missing some
point. 
Probably this has been discussed before, so I apologize
for consuming the bandwidth.]

David, do you think this whole issue is important enough?

I apologize for consuming the bandwidth to those who are not 
interested...

Andras

-----------------------------------------------------------------------
Message addressed to: [e-mail]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [e-mail]