Re: [eppext] New draft for keyrelay available

[Antoin Verschuren <[e-mail]>]

Op 5 feb. 2015, om 15:08 heeft Gould, James <[e-mail]> het volgende geschreven:

> I believe that RFC 5730 is not limited to a certain class of objects that can be provisioned.  A create of a transient, immutable message object is a transform command and the use of a poll response supports a query command.  

Apologies James if I am confused. 

So the question boiles down to:

-What is meant by "object” in RFC5730?

The authors believe what is meant here with "object" is something stored in the registry database that requires uniqueness and ownership. Not all EPP commands can be performed on all objects, A database can be extended with new objects which will require an extension to provision the new object, or an existing object could be extended with new records which needs an extension of the command to provision the new records.
You think "object" does not relate to a registry database table and can be any data blob in the communication stream as well.

If we all agree that an object means any blob, should that be clarified in RFC5730?
At least I am confused when object does not refer to an object in the registry database, as I cannot verify uniqueness and consistancy of the EPP processes over the database.

> My recommendation to the authors of the Key Relay Extension is to make the draft an object mapping with a create transform command, a the poll response, and with a unique relay identifier to address the end-to-end idempotency concern.  

I don’t see the need for a seperate unique relay identifier. Since the timestamp can be part of the calculation of the expiry of the relayed key, no second message is identical. If and only if the timestamp is different and the expiry is not dependant of the timestamp and the rest of the message is identical can the message be disguarded as identical, but we don’t need a duplicate field to identify that, and it is left to the receiver how to interpret that. There may be future use cases where only the timestamp is different but where the message is valid and needs to be processed by the receiver.

- -- 
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: [phone]
xmpp:[e-mail]