Subject: "status" element in <domain:info> response

From: "Liu, Hong" <[email-masked]>
Date: Wed, 11 Sep 2002 09:19:59 -0400

Scott,

I have another question for clarification regarding the "status" element in
<domain:info> response for Domain -05. (Actually, similar text appears in
Domain -04).

On page 12, in describing <domain:status>, it says "One or more OPTIONAL".
But in the domain-1.0.xsd schema on page 38, the cardinality of <status> in
"infDataType" is minOccurs="0" and maxOccurs="12".

There are two issues involved:
(1) Should the description on page 12 be changed from "One" to "Zero"?
(2) Should a cap be put on the number of statii returned? If so, is the cap
value "12" or "17"? When I check the "statusValueType" on page 39, there are
17 values defined in the schema. 

Could you please make them consistent? Thanks!

--Hong

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 11 Sep 2002 09:48:15 -0400

> (1) Should the description on page 12 be changed from "One" to "Zero"?

No, because there always has to be at least one status value.  It should be
changed to remove the word "OPTIONAL".  The schema should be changed to
remove minOccurs="0".

> 17 values defined in the schema.

Re-read section 2.3.  There may be 17 values defined, but they can't all be
present at the same time.

-Scott-

---

From: "Liu, Hong" <[email-masked]>
Date: Wed, 11 Sep 2002 10:54:54 -0400

Scott, please see my comments below. 

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, September 11, 2002 9:48 AM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: "status" element in <domain:info> response

<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>

<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>

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 11 Sep 2002 14:20:06 -0400

> example package need to be fixed to include at least one status value.

Sigh, you found the spot I forgot that explains why it's OPTIONAL and zero
is possible.  Back to zero being the minimum.

> derived from the complex rules in section 2.3. Could you 

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-

---

From: "Liu, Hong" <[email-masked]>
Date: Thu, 12 Sep 2002 13:09:30 -0400

Thanks, Scott. That will do it.

-----Original Message-----
From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Wednesday, September 11, 2002 2:20 PM
To: 'Liu, Hong'; [email-masked]'
Subject: RE: "status" element in <domain:info> response

clientDeleteProhibited
clientHold
clientRenewProhibited
clientTransferProhibited
clientUpdateProhibited
inactive
serverDeleteProhibited
serverHold
serverRenewProhibited
serverTransferProhibited
serverUpdateProhibited

-Scott-