Re: Inconsistent Domain Status Value Guidance in RFC 5731
Marc Groeneweg <[email protected]> Fri, 11 Sep 2015 12:16:55 +0000
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
--_002_5BFD186DCB661E4D951017B0818285AEDE78815Dkambx2SIDNlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pfew, Scott, This goes way back to the original RFC3731, where the exact text exists. I = have found an email discussing the status field with zero and more... (sigh= , september 2002).=20 Regards, Marc=20 -----Original Message----- From: provreg [mailto:[email protected]] On Behalf Of Hollenbeck, Sc= ott Sent: vrijdag 11 september 2015 13:28 To: [email protected] Subject: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731 I received a mail note from someone asking about a difference in the text t= hat appears in RFC 5731 and the schema that is supposed to support that tex= t. First, the text from Section 2.3: "A domain object MUST always have at least one associated status value". Text from Section 3.1.2 (info response): "Zero or more OPTIONAL <domain:status> elements that contain the current st= atus descriptors associated with the domain" The schema matches the 3.1.2 text. I can't remember why or how we ended up = with text that says "MUST always have at least one" in one section and "Zer= o or more OPTIONAL" in another section. Does this tickle any memories for a= nyone? Scott _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg --_002_5BFD186DCB661E4D951017B0818285AEDE78815Dkambx2SIDNlocal_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Fri, 11 Sep 2015 12:16:01 GMT"; modification-date="Fri, 11 Sep 2015 12:16:01 GMT" From: "Liu, Hong <[email protected]>" To: "[email protected]" Subject: RE: "status" element in <domain:info> response Thread-Topic: "status" element in <domain:info> response Thread-Index: Ac3kNLF8QX4y4yG1TRuwOic/Tky1SQ== Date: Thu, 12 Sep 2002 17:09:30 +0000 Message-ID: <[email protected]> Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="_004_4F9D157E1D347A4E9EBCE02C45FE811016C6B7sidn2002000sidnnl_" MIME-Version: 1.0 --_004_4F9D157E1D347A4E9EBCE02C45FE811016C6B7sidn2002000sidnnl_ Content-Type: multipart/alternative; boundary="_000_4F9D157E1D347A4E9EBCE02C45FE811016C6B7sidn2002000sidnnl_" --_000_4F9D157E1D347A4E9EBCE02C45FE811016C6B7sidn2002000sidnnl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Scott. That will do it. -----Original Message----- From: Hollenbeck, Scott [mailto:[email protected]] Sent: Wednesday, September 11, 2002 2:20 PM To: 'Liu, Hong'; '[email protected]' 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> 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 sam= e time. An object also can't be in both "ok" and any other status at the sam= e 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- --_000_4F9D157E1D347A4E9EBCE02C45FE811016C6B7sidn2002000sidnnl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <!-- converted from rtf --> <style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:= #800000 2px solid; } --></style> </head> <body> <font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12pt;"> <div>Thanks, Scott. That will do it.</div> <div> </div> <div>‑‑‑‑‑Original Message‑‑̴= 9;‑‑</div> <div>From: Hollenbeck, Scott [<a href=3D"mailto:[email protected]">m= ailto:[email protected]</a>]</div> <div>Sent: Wednesday, September 11, 2002 2:20 PM</div> <div>To: 'Liu, Hong'; 'ietf‑[email protected]'</div> <div>Subject: RE: "status" element in <domain:info> respons= e</div> <div> </div> <div> </div> <div>> <HL></div> <div>> Thanks for the clarification. If at least one status tag </div> <div>> should exist, then</div> <div>> the example on page 15 as well as the </div> <div>> domain_info_unauth_result.xml in the</div> <div>> example package need to be fixed to include at least one status v= alue.</div> <div>> </HL></div> <div> </div> <div>Sigh, you found the spot I forgot that explains why it's OPTIONAL and = zero</div> <div>is possible. Back to zero being the minimum.</div> <div> </div> <div>> <HL></div> <div>> You are right, not all 17 values are allowed to co‑exist at= </div> <div>> the same time</div> <div>> according to section 2.3. But I am having difficulty </div> <div>> understanding how 12 is</div> <div>> derived from the complex rules in section 2.3. Could you </div> <div>> explain that to me?</div> <div>> Thanks! </div> <div>> </HL></div> <div> </div> <div>The "pending" status values can't be set if the correspondin= g "prohibited"</div> <div>status values are set; all of the "prohibited" values can be= set at the same</div> <div>time. An object also can't be in both "ok" and any oth= er status at the same</div> <div>time. The combination with the greatest number of members is thu= s:</div> <div> </div> <div>clientDeleteProhibited</div> <div>clientHold</div> <div>clientRenewProhibited</div> <div>clientTransferProhibited</div> <div>clientUpdateProhibited</div> <div>inactive</div> <div>serverDeleteProhibited</div> <div>serverHold</div> <div>serverRenewProhibited</div> <div>serverTransferProhibited</div> <div>serverUpdateProhibited</div> <div> </div> <div>That's 11. OK, so I missed by one ;‑). I'll check th= e contact and host</div> <div>combinations again to be sure they're right, too.</div> <div> </div> <div>‑Scott‑</div> </span></font> </body> </html> --_000_4F9D157E1D347A4E9EBCE02C45FE811016C6B7sidn2002000sidnnl_-- --_004_4F9D157E1D347A4E9EBCE02C45FE811016C6B7sidn2002000sidnnl_ Content-Type: application/octet-stream; name="Mime.822" Content-Description: Mime.822 Content-Disposition: attachment; filename="Mime.822"; size=3476; creation-date="Tue, 04 Mar 2003 19:09:37 GMT"; modification-date="Tue, 04 Mar 2003 19:09:37 GMT" Content-Transfer-Encoding: base64 UmVjZWl2ZWQ6IGZyb20gZW1tYS5rZW1hLm5sDQoJYnkgZ3ctZ3cua2VtYS5ubDsgVGh1LCAxMiBT ZXAgMjAwMiAxOToyMTozMCArMDIwMA0KUmVjZWl2ZWQ6IGZyb20gZG5zMS5rZW1hLm5sIChmdyBb MTk0LjUzLjI1Mi4xXSkgYnkgZW1tYS5rZW1hLm5sICg4LjcuNS84LjYuMTIpIHdpdGggRVNNVFAg aWQgVEFBMTcyODkgZm9yIDxNLlcuR3JvZW5ld2VnQGtlbWEubmw+OyBUaHUsIDEyIFNlcCAyMDAy IDE5OjIxOjMwICswMjAwIChNRVREU1QpDQpSZWNlaXZlZDogKGZyb20gcm9vdEBsb2NhbGhvc3Qp IGJ5IGRuczEua2VtYS5ubCAoOC45LjFhLzguNi4xMikgaWQgVEFBMjE1NzggZm9yIDxNLlcuR3Jv ZW5ld2VnQGtlbWEubmw+OyBUaHUsIDEyIFNlcCAyMDAyIDE5OjIxOjMwICswMjAwIChNRVQgRFNU KQ0KUmVjZWl2ZWQ6IGJ5IGRuczEua2VtYS5ubCB2aWEgc21hcCAoVjEuMykNCglpZCBzbWEwMjEw MTg7IFRodSwgMTIgU2VwIDAyIDE5OjIxOjE2ICswMjAwDQpSZWNlaXZlZDogZnJvbSBuaWMuY2Fm YXguc2UgKGxvY2FsaG9zdCBbMTI3LjAuMC4xXSkNCglieSBuaWMuY2FmYXguc2UgKDguMTIuNS84 LjEyLjUpIHdpdGggRVNNVFAgaWQgZzhDSDllbzIwMDQ5MDINCglmb3IgPGlldGYtcHJvdnJlZy1v dXRnb2luZ0BuaWMuY2FmYXguc2U+OyBUaHUsIDEyIFNlcCAyMDAyIDE5OjA5OjQwICswMjAwIChN RVNUKQ0KUmVjZWl2ZWQ6IGJ5IG5pYy5jYWZheC5zZSAoOC4xMi41LzguMTIuNS9TdWJtaXQpIGlk IGc4Q0g5ZGNSMDA0OTAxDQoJZm9yIGlldGYtcHJvdnJlZy1vdXRnb2luZzsgVGh1LCAxMiBTZXAg MjAwMiAxOTowOTozOSArMDIwMCAoTUVTVCkNClgtQXV0aGVudGljYXRpb24tV2FybmluZzogbmlj LmNhZmF4LnNlOiBtYWpvcmRvbSBzZXQgc2VuZGVyIHRvIG93bmVyLWlldGYtcHJvdnJlZ0BjYWZh eC5zZSB1c2luZyAtZg0KUmVjZWl2ZWQ6IGZyb20gb2FrLm5ldXN0YXIuY29tIChvYWsubmV1c3Rh ci5jb20gWzIwOS4xNzMuNTMuNzBdKQ0KCWJ5IG5pYy5jYWZheC5zZSAoOC4xMi41LzguMTIuNSkg d2l0aCBFU01UUCBpZCBnOENIOWNvMjAwNDg5Ng0KCWZvciA8aWV0Zi1wcm92cmVnQGNhZmF4LnNl PjsgVGh1LCAxMiBTZXAgMjAwMiAxOTowOTozOCArMDIwMCAoTUVTVCkNClJlY2VpdmVkOiBmcm9t IHN0bnRpbWMxLnZhLm5ldXN0YXIuY29tIChzdG50aW1jMS52YS5uZXVzdGFyLmNvbSBbMTAuMzEu MTMuMTFdKQ0KCWJ5IG9hay5uZXVzdGFyLmNvbSAoOC4xMS4wLzguMTEuMCkgd2l0aCBFU01UUCBp ZCBnOENIOVpHMDg0OTINCglmb3IgPGlldGYtcHJvdnJlZ0BjYWZheC5zZT47IFRodSwgMTIgU2Vw IDIwMDIgMTc6MDk6MzUgR01UDQpSZWNlaXZlZDogYnkgU1ROVElNQzEgd2l0aCBJbnRlcm5ldCBN YWlsIFNlcnZpY2UgKDUuNS4yNjUzLjE5KQ0KCWlkIDxSWjdXQkxaSj47IFRodSwgMTIgU2VwIDIw MDIgMTM6MTA6NDMgLTA0MDANCk1lc3NhZ2UtSUQ6IDw1RTQyQzFDODVDNUQwNjRBOTQ3Q0Y5MkZB REU2RDgyRTNFQzJGREBTVE5URVhDSDE+DQpGcm9tOiAiTGl1LCBIb25nIiA8SG9uZy5MaXVAbmV1 c3Rhci5iaXo+DQpUbzogIidpZXRmLXByb3ZyZWdAY2FmYXguc2UnIiA8aWV0Zi1wcm92cmVnQGNh ZmF4LnNlPg0KU3ViamVjdDogUkU6ICJzdGF0dXMiIGVsZW1lbnQgaW4gPGRvbWFpbjppbmZvPiBy ZXNwb25zZQ0KRGF0ZTogVGh1LCAxMiBTZXAgMjAwMiAxMzowOTozMCAtMDQwMA0KTUlNRS1WZXJz aW9uOiAxLjANClgtTWFpbGVyOiBJbnRlcm5ldCBNYWlsIFNlcnZpY2UgKDUuNS4yNjUzLjE5KQ0K Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9Imlzby04ODU5LTEiDQpTZW5kZXI6 IG93bmVyLWlldGYtcHJvdnJlZ0BjYWZheC5zZQ0KUHJlY2VkZW5jZTogYnVsaw0KDQpUaGFua3Ms IFNjb3R0LiBUaGF0IHdpbGwgZG8gaXQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBIb2xsZW5iZWNrLCBTY290dCBbbWFpbHRvOnNob2xsZW5iZWNrQHZlcmlzaWduLmNvbV0N ClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDExLCAyMDAyIDI6MjAgUE0NClRvOiAnTGl1LCBI b25nJzsgJ2lldGYtcHJvdnJlZ0BjYWZheC5zZScNClN1YmplY3Q6IFJFOiAic3RhdHVzIiBlbGVt ZW50IGluIDxkb21haW46aW5mbz4gcmVzcG9uc2UNCg0KDQo+IDxITD4NCj4gVGhhbmtzIGZvciB0 aGUgY2xhcmlmaWNhdGlvbi4gSWYgYXQgbGVhc3Qgb25lIHN0YXR1cyB0YWcgDQo+IHNob3VsZCBl eGlzdCwgdGhlbg0KPiB0aGUgZXhhbXBsZSBvbiBwYWdlIDE1IGFzIHdlbGwgYXMgdGhlIA0KPiBk b21haW5faW5mb191bmF1dGhfcmVzdWx0LnhtbCBpbiB0aGUNCj4gZXhhbXBsZSBwYWNrYWdlIG5l ZWQgdG8gYmUgZml4ZWQgdG8gaW5jbHVkZSBhdCBsZWFzdCBvbmUgc3RhdHVzIHZhbHVlLg0KPiA8 L0hMPg0KDQpTaWdoLCB5b3UgZm91bmQgdGhlIHNwb3QgSSBmb3Jnb3QgdGhhdCBleHBsYWlucyB3 aHkgaXQncyBPUFRJT05BTCBhbmQgemVybw0KaXMgcG9zc2libGUuICBCYWNrIHRvIHplcm8gYmVp bmcgdGhlIG1pbmltdW0uDQoNCj4gPEhMPg0KPiBZb3UgYXJlIHJpZ2h0LCBub3QgYWxsIDE3IHZh bHVlcyBhcmUgYWxsb3dlZCB0byBjby1leGlzdCBhdCANCj4gdGhlIHNhbWUgdGltZQ0KPiBhY2Nv cmRpbmcgdG8gc2VjdGlvbiAyLjMuIEJ1dCBJIGFtIGhhdmluZyBkaWZmaWN1bHR5IA0KPiB1bmRl cnN0YW5kaW5nIGhvdyAxMiBpcw0KPiBkZXJpdmVkIGZyb20gdGhlIGNvbXBsZXggcnVsZXMgaW4g c2VjdGlvbiAyLjMuIENvdWxkIHlvdSANCj4gZXhwbGFpbiB0aGF0IHRvIG1lPw0KPiBUaGFua3Mh IA0KPiA8L0hMPg0KDQpUaGUgInBlbmRpbmciIHN0YXR1cyB2YWx1ZXMgY2FuJ3QgYmUgc2V0IGlm IHRoZSBjb3JyZXNwb25kaW5nICJwcm9oaWJpdGVkIg0Kc3RhdHVzIHZhbHVlcyBhcmUgc2V0OyBh bGwgb2YgdGhlICJwcm9oaWJpdGVkIiB2YWx1ZXMgY2FuIGJlIHNldCBhdCB0aGUgc2FtZQ0KdGlt ZS4gIEFuIG9iamVjdCBhbHNvIGNhbid0IGJlIGluIGJvdGggIm9rIiBhbmQgYW55IG90aGVyIHN0 YXR1cyBhdCB0aGUgc2FtZQ0KdGltZS4gIFRoZSBjb21iaW5hdGlvbiB3aXRoIHRoZSBncmVhdGVz dCBudW1iZXIgb2YgbWVtYmVycyBpcyB0aHVzOg0KDQpjbGllbnREZWxldGVQcm9oaWJpdGVkDQpj bGllbnRIb2xkDQpjbGllbnRSZW5ld1Byb2hpYml0ZWQNCmNsaWVudFRyYW5zZmVyUHJvaGliaXRl ZA0KY2xpZW50VXBkYXRlUHJvaGliaXRlZA0KaW5hY3RpdmUNCnNlcnZlckRlbGV0ZVByb2hpYml0 ZWQNCnNlcnZlckhvbGQNCnNlcnZlclJlbmV3UHJvaGliaXRlZA0Kc2VydmVyVHJhbnNmZXJQcm9o aWJpdGVkDQpzZXJ2ZXJVcGRhdGVQcm9oaWJpdGVkDQoNClRoYXQncyAxMS4gIE9LLCBzbyBJIG1p c3NlZCBieSBvbmUgOy0pLiAgSSdsbCBjaGVjayB0aGUgY29udGFjdCBhbmQgaG9zdA0KY29tYmlu YXRpb25zIGFnYWluIHRvIGJlIHN1cmUgdGhleSdyZSByaWdodCwgdG9vLg0KDQotU2NvdHQtDQo= --_004_4F9D157E1D347A4E9EBCE02C45FE811016C6B7sidn2002000sidnnl_-- --_002_5BFD186DCB661E4D951017B0818285AEDE78815Dkambx2SIDNlocal_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg --_002_5BFD186DCB661E4D951017B0818285AEDE78815Dkambx2SIDNlocal_--