RE: "status" element in <domain:info> response
"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 11 September 2002 18:24 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 OAA20262 for <provreg-archive@ietf.org>; Wed, 11 Sep 2002 14:24:42 -0400 (EDT)
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BIKHo2024869 for <ietf-provreg-outgoing@nic.cafax.se>; Wed, 11 Sep 2002 20:20:17 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id g8BIKH2e024868 for ietf-provreg-outgoing; Wed, 11 Sep 2002 20:20:17 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id g8BIKFo2024862 for <ietf-provreg@cafax.se>; Wed, 11 Sep 2002 20:20:16 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id OAA01078; Wed, 11 Sep 2002 14:21:04 -0400 (EDT)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <RV4GTKK1>; Wed, 11 Sep 2002 14:20:06 -0400
Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60336FECD@vsvapostal3.prod.netsol.com>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "'Liu, Hong'" <Hong.Liu@neustar.biz>, "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
Subject: RE: "status" element in <domain:info> response
Date: Wed, 11 Sep 2002 14:20:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk
> <HL> > Thanks for the clarification. If at least one status tag > should exist, then > the example on page 15 as well as the > domain_info_unauth_result.xml in the > example package need to be fixed to include at least one status value. > </HL> Sigh, you found the spot I forgot that explains why it's OPTIONAL and zero is possible. Back to zero being the minimum. > <HL> > You are right, not all 17 values are allowed to co-exist at > the same time > according to section 2.3. But I am having difficulty > understanding how 12 is > derived from the complex rules in section 2.3. Could you > explain that to me? > Thanks! > </HL> The "pending" status values can't be set if the corresponding "prohibited" status values are set; all of the "prohibited" values can be set at the same time. An object also can't be in both "ok" and any other status at the same time. The combination with the greatest number of members is thus: clientDeleteProhibited clientHold clientRenewProhibited clientTransferProhibited clientUpdateProhibited inactive serverDeleteProhibited serverHold serverRenewProhibited serverTransferProhibited serverUpdateProhibited That's 11. OK, so I missed by one ;-). I'll check the contact and host combinations again to be sure they're right, too. -Scott-
- RE: "status" element in <domain:info> response Hollenbeck, Scott
- "status" element in <domain:info> response Liu, Hong
- RE: "status" element in <domain:info> response Liu, Hong
- RE: "status" element in <domain:info> response Hollenbeck, Scott
- RE: "status" element in <domain:info> response Liu, Hong