[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'Bernie Hoeneisen'" <bhoeneis@switch.ch>
Cc: ietf-provreg@cafax.se
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Wed, 2 Jul 2003 09:20:06 -0400
Sender: owner-ietf-provreg@cafax.se
Subject: RE: [ietf-provreg] Some EPP questions

> I rather want to stress out, that future extensions might need such
> possibilities as provided by the 'op=__' command attribute of 
> the transfer
> command only. And if I understood the guidelines for epp 
> extensions draft
> correctly, it is not possible to add e.g. an 'op=__' command 
> attribute to
> the existing protocol commands (create, delete, update, ...), and thus
> either a new protocol level extension would have to be 
> defined, or some
> child element would have to be defined with different looking 
> syntax for
> the same semantics (as the 'op=__' command attribute) in the transfer.
> Please tell me if I understood things wrong.

You're right, and that's how it's supposed to work.  The functionality
you're describing can always be added as extensions if/when someone wants
them.
 
> Assuming the response to a transfer command is 1001 "Command completed
> successfully; action pending". What would the server answer to a
> transfer query command (assuming nothing concerning this transfer has
> changed at server since the 1001 was sent)?

There's nothing that should stop a query from being answered completely, so
a 1000 response code is appropriate.  Remember that each response code is
related directly to the command it is being sent for and it becomes easier
to remember which code is appropriate.

-Scott-

Home | Date list | Subject list