Re: EPP/TCP session layer

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

Moring Robert,

The usage in draft-ietf-provreg-epp-tcp-04.txt, section 2, paragraph 3, of
"monimally" is not "existing in name only". Please see the following:

draft-ietf-provreg-epp-06.txt, section 3, Result Codes (at line 2647)
  1000    "Command completed successfully"
  This is the nominal response code for a successfully completed
  command.

draft-ietf-provreg-epp-beep-01.txt, section 2, Session Management (at 147)
   An EPP session is nominally ended by the client issuing an EPP
   <logout> command which terminates the respective BEEP channel.  A  
   server receiving an EPP <logout> command MUST end the EPP session and
   release the BEEP channel.


draft-ietf-provreg-epp-contact-04.txt, section 2.2, Status Values (at 242)
  ok
      
  This is the nominal status value for an object that has no pending
  operations or prohibitions.

The same usages are also in:
draft-ietf-provreg-epp-container-01.txt, section 2.5, Status Values (at 638)
draft-ietf-provreg-epp-domain-04.txt, section 2.3, Status Values (at 260)
draft-ietf-provreg-epp-host-04.txt, section 2.3, Status Values (at 242)


See also:
draft-ietf-provreg-grrp-reqs-06.txt, at 744,

3.5 Domain Status Indicators

  [1] The protocol MUST provide status indicators that identify the
  operational state of a domain name.  Indicators MAY be provided to
  identify a newly created state (the domain has been registered but has
  not yet appeared in a zone), a nominal active state (the domain can be
  modified and is published in a zone), an inactive state (the domain
  can be modified but is not published in a zone because it has no
  authoritative name servers), a hold state (the domain can not be
  modified and is not published in a zone), a lock state (the domain can
  not be modified and is published in a zone), a pending transfer state,
  and a pending removal state.

and at 963, 

7.4 Maintainability
  
  [1] Maintainability is a measure of the extent to which a protocol can
  be adapted or modified to address unforeseen operational needs or
  defects.  The protocol SHOULD be developed under the nominal working  
  group processes of the IETF to provide a well-known mechanism for  
  ongoing maintenance.

I confess I hadn't given the datagram section any thought at all. From an
implementor point of view isn't this equivalent to doing one write to the
wire per command or response?

I'm interested in understanding the scenario where two wf epp xml instances
(not equivalent, due to idempotency) exist in one socket buffer, for the use
case of transport over tcp. 

Cheers,
Eric