These notes cover the RDAP Working Session on Monday, March 27. Andrew Fregly, the note taker was not familiar with the attendees so only a few are identified here-in.
Session Overview ---------------- Scott Hollenbeck: Meeting will cover three RDAP-related drafts. Overview of drafts was provided. Discussions relative to each follow. draft-fregly-regext-rdap-search-regex ------------------------------------- Provides rich search capability missing from original RDAP search specification. Searches are specified using POSIX Regular Expressions. Hex encoding was discussed as an alternative to the Base64 URL encoding of search expressions specified in the draft. Authors and attendee who brought this up to investigate further. Discussion of advertising REGEX search capability (and other RDAP extensions) by RDAP services that support it. Andy Fregly: Use help endpoint Marcos Sanz: Prefers advertisement. Scott: This is an instance of a more general RDAP issue. Scott: Asks for indication of who is going to do implementations of the search capability. no indication that anyone is going to implement. Scott: We will not ask the working group to consider adoption. draft-hollenbeck-regext-rdap-object-tag --------------------------------------- Scott: describes need for IANA registry for tags based on existing RIR practice. Attendee: pushes back on need for IANA registry Discussion ends when consensus it reached that a registry is required. Scott: Indicates the draft may be a good candidate for BCP status Attendee: Points out that delimiters for tags could result in ambiguity in parsing, this opening the door for hacks. Scott: Delimiters were chosen because they were not used in current practice (as far as we know) Another Attendee: says delimiters were used by their service Discussion of appropriate delimiters to be taken to the mailing list. Scott: Asks for indication of who would implement the capability. A handful of people indicate they would implement An Attendee: States that the problem being solved wasn't an issue as his service only returns data that it has (an indication that it is not concerned about data at another service). Scott: There was enough interest that further mailing list discussions would occur with intention to have the working group consider document adoption. draft-hollenbeck-regext-rdap-openid ----------------------------------- Scott: describes authentication and authorization drivers and Verisign's implementation of the draft with support for several public OpenID Connect providers and Verisign's own provider. Scott: Describes limitation that OpenID Connect requires a hack to support command-line clients (wget and curl as examples). Attendee: Describes similar hack for Twitter client. Attendee: Suggests API keys as alternative. No support for API key as an alternative. Attendee: States that an interaction diagram would help in understanding the protocol. Scott: Indicates this could be done. Scott: Scott asks for indication of who would implement the capability. Indication is positive Scott: There is enough interest to continue evolving the document and eventually ask the working group to consider document adoption. Recap ----- Scott: Notes documents are all in draft state and not working group documents. Asks for final feedback and suggestions. Notes that fixes and corrections can be made before docs become working group documents. Asks for further interaction on the mailing list. Andy Newton: Notes that his implementation of rdap-openid being subject to denial of service attack was an example of need for further consideration of the capabilities. Attendee: Notes that the REGEX search capability would be particularly vulnerable to denial of service attacks. Marcos Sanz: Voices concern over complexity of JCARD versus VCARD Scott: Decision was made due to "IETF Consensus" and reuse of existing standards Scott: Ends discussion with request for more participation on the mailing list. Fregly, Andrew afre...@verisign.com work mobile: 571-305-3014 work desk: 703-948-4649 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
