Le 2014-10-15 à 15:20, Alessandro Vesely <vesely(_at_)tana(_dot_)it> a écrit :
On Tue 14/Oct/2014 00:25:29 +0200 The IESG wrote:
The IESG has received a request from the Web Extensible Internet
Registration Data Service WG (weirds) to consider the following document:
- 'Finding the Authoritative Registration Data (RDAP) Service'
<draft-ietf-weirds-bootstrap-09.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2014-10-27.
A couple of notes. In the *Introduction*:
The required new functionality in support of RDAP could be
accomplished by augmenting these registries to contain new fields,
or creating second parallel registries containing the extra fields
whose entries mirror the existing ones. Either approach will
satisfy the needs of this document.
This is a hint to IANA, which might be moved to Section 12. It may
sound confusing to client implementors. If it is moved, the next
sentence could be reworded to read, e.g.:
This document requests IANA to make an augmented version of the
existing registries available for the specific purpose of RDAP
use, herein named RDAP Bootstrap Service Registries.
done in -10.
In Section 4, *Domain Name RDAP Bootstrap Service Registry*, the
concept of longest match doesn't make sense. Say url1 does "com" and
"net" while url2 does "com" only, then one will find:
"services": [[["com", "net"], [url1]], [["com"], [url2]]]
(An alternative, possibly easier for a client who needs to resolve a
"com" domain, would be:
"services": [[["com"], [url1, url2]], [["com", "net"], [url1]]]
)
IANA delegates root entries only (not co.uk) so the /longest/ match is
actually an /equal/ match, meaning that there might be multiple
entries for a given name in different second-level arrays, as in the
non-parenthesized case above. Correct?
disagree. This has been discussed a lot during the wg work.
- we don’t want to restrict the lookup to single TLD, for technical and policy
reasons.
- given large concentration of registries managed by single organisations, and
the fact that just for tlds, there is a large amount of tlds coming…, there was
an agreement for the structure in the draft to support multiple entries per
rdap server.
so rejecting this one.
Finally, in Section 6 *Entity*, it is not obvious what one means by
"entity". Perhaps is might be worth to insert a preamble, e.g.:
Entities (such as contacts, registrants, or registrars) can be
queried by handle as described in [I-D.ietf-weirds-rdap-query].
However, since there is no global namespace for entities, this
document does not describe how to find…
ok. thanks. done in -10.
Marc.
jm2c
Ale