Hi Jim,
> Upon my first review, I find the extension to be an interesting aggregation
> concept. I’m not exactly sure why the client wouldn’t just make separate
> calls to get the same information.
Yes, it can, but I believe there is some efficiency that can be achieved in
terms of roundtrips.
> With that, I have the following feedback:
>
> • I don’t see the purpose of the <ro:include> child element of the
> <ro:info> element, where the child elements can be directly under the
> <ro:info> element.
That choice was purely aesthetic, in that the <include> element conveys
semantics in a human readable way.
> • It would be good to include a mapping of the response elements with the
> command elements, along with an indication of existence or ability to include
> the information. Such as including the <ro:registrant>, <ro:contacts>, and
> <ro:orgs>, <ro:ns>, <ro:hosts>, and <ro:other> elements as children of the
> <ro:infData> element with some indication of existence or a disclosure issue.
> The objects can be contained under those ro elements.
Yes, this was something I'd been thinking about. At the moment the related
objects are included "naked", but I had been thinking about something like this:
<ro:infData>
<ro:object type="contact"
roid="SH8013-REP"><contact:infData>...</contact:infData></ro:object>
<ro:object type="contact" roid="SH8014-REP" code="2201" msg="Authorization
error" />
</ro:infData>
Where an object cannot be included, then the <ro:object> would be empty but
would have "code" and "msg" attributes that would mirror the values that the
client would see if they did an <info> command on the same object.
G.
--
Gavin Brown
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com
CentralNic Group plc is a company registered in England and Wales with company
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V
6BR.
https://www.centralnic.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
