Re: EPP/TCP session layer
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net> Mon, 08 April 2002 11:10 UTC
Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20069 for <provreg-archive@ietf.org>; Mon, 8 Apr 2002 07:10:33 -0400 (EDT)
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g38B2kd1024954 for <ietf-provreg-outgoing@nic.cafax.se>; Mon, 8 Apr 2002 13:02:46 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0/Submit) id g38B2k89024953 for ietf-provreg-outgoing; Mon, 8 Apr 2002 13:02:46 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from nic-naa.net (dt0b4n7d.maine.rr.com [24.95.12.125]) by nic.cafax.se (8.12.3.Beta0/8.12.3.Beta0) with ESMTP id g38B2jd1024948 for <ietf-provreg@cafax.se>; Mon, 8 Apr 2002 13:02:45 +0200 (MEST)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.11.6/8.11.1) with ESMTP id g38AuUX58676; Mon, 8 Apr 2002 06:56:30 -0400 (EDT) (envelope-from brunner@nic-naa.net)
Message-Id: <200204081056.g38AuUX58676@nic-naa.net>
To: Robert Burbidge <robert.burbidge@poptel.coop>
cc: "Ietf-Provreg (E-mail)" <ietf-provreg@cafax.se>, brunner@nic-naa.net
Subject: Re: EPP/TCP session layer
In-Reply-To: Your message of "Mon, 08 Apr 2002 10:43:49 BST." <F9151633A30CD4118C9D00062939A7F19A3FCF@popintlonex.poptel.org.uk>
Date: Mon, 08 Apr 2002 06:56:30 -0400
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk
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
- EPP/TCP session layer Robert Burbidge
- Re: EPP/TCP session layer Eric Brunner-Williams in Portland Maine
- RE: EPP/TCP session layer Hollenbeck, Scott