Hi, Passing the extra data via a key / value pair extension or with use of a new specific extension does not remove the need for defining what the data is, where it must / should / may be passed, and what the behavior is expected based on the data. In your case of the language for each contact created, let’s consider some the questions associated with using a key / value pair extension:
1. What key is used (e.g., “LANG”, “LANGUAGE”, “MESSAGE-LANGUAGE”), and I would assume that the key is case insensitive but that should be clarified? a. Is there a scheme that must be used for the keys, are the keys required to be registered in an IANA registry, and what additional information must be included in introducing a new key? 2. What are the possible values for the language key (e.g., ISO 639-1, ISO 639-2, ISO 639-3, Language name, Native language name)? 3. Is your use of the language key consistent with other servers, where you state that it determines what language to send messages to the contact? a. What are the messages (e.g., EPP poll message, e-mails, text), what format are the messages, and who receives the messages (registrar, registrant)? b. Is the language displayed in Whois? c. Is the language used for other purposes like translation or transliteration and if so which contact fields? 4. What commands and responses is the language key used with? a. Should there be a mechanism to ensure that the language is supported prior to the create by using the language key in the extension to the check command and response? b. Is the language key returned in an info response based on use of the login services? c. Is the language key optional or required on create? d. Can the language by updated via an extension to the update command? e. What happens to the language key upon transfer? I’m sure additional questions would come up in discussing the idea of supporting the passing of a language to contacts, whether it’s via a key / value pair extension or a specific extension. In the end, use of a key / value pair is a quick implementation solution, but it does not fully define what is needed for effective communication between the EPP client and server. — JG [cid:image001.png@01D2BDC8.E25B2A60] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> From: Tongfeng Zhang <tongfeng.zh...@cira.ca> Date: Tuesday, April 25, 2017 at 11:40 AM To: James Gould <jgo...@verisign.com>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] RE: [regext] EPP extension to take in generic key value pairs Thank you James for your response. For us, I could see it being useful in a few cases when we need to take in some extra data for an entity and those data are only for info and/or internal usage. For example, we take in a value for language for each contact created in our system. The value will determine in what language we send messages to the contact. Thanks, Tongfeng From: Gould, James [mailto:jgo...@verisign.com] Sent: Wednesday, April 19, 2017 2:38 PM To: Tongfeng Zhang; regext@ietf.org Subject: Re: [regext] EPP extension to take in generic key value pairs Hi, We created a key / value pair extension called the “Common Object Attribute (COA) Extension for the Extensible Provisioning Protocol (EPP)” that was registered in the EPP Extensions Registry (https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml ). Use of COA has been considered on numerous occasions, but the problem always morphed into something too complex for a simple key / value pair, resulting in creation of a specific extension. There is no typing, there is no containment mechanism, and most importantly there is no definition for the supported set of keys and when the keys are used. You could create a key registry to ensure that keys have a consistent meaning. Take a look at one of the simplest extensions, being the Allocation Token Extension (https://tools.ietf.org/html/draft-ietf-regext-allocation-token), where initially you could use a pre-defined key (e.g., “ALLOCATION-TOKEN”), with the value being the allocation token. Then when you start thinking using an Allocation Token, you want to extend the check command to check the availability of a domain name using the allocation token. And then when you think about it some more, you want to then get the Allocation Token used via the info command and response. You could attempt to solve the check command / response, create command, and info command / response behavior with use of a general key / value pair extension with one or more pre-defined keys, but then you have a need to define when you use the keys and what the expected behavior is. Even though the Allocation Token Extension is yet another EPP extension, it meets a specific purpose explicitly and is defined in one place. In the end, I view the use of a general key / value pair extension as being too rudimentary for use in communication between the EPP clients and servers. — JG [cid:image002.png@01D2BDC8.E25B2A60] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on behalf of Tongfeng Zhang <tongfeng.zh...@cira.ca<mailto:tongfeng.zh...@cira.ca>> Date: Wednesday, April 19, 2017 at 1:22 PM To: "regext@ietf.org<mailto:regext@ietf.org>" <regext@ietf.org<mailto:regext@ietf.org>> Subject: [EXTERNAL] [regext] EPP extension to take in generic key value pairs Dear colleagues, While adding some unrelated features to our registry platform, I thought of adding an EPP extension of accept generic key/value pairs for an entity (domain, contact, or host) instead of creating 1 specific extension per feature. I was wondering if anyone’s implemented similar extensions in your registry. Appreciated if you could share your experience (pros and cons). Also, would like to know your onion on a making such extension a standard. Thanks, Tongfeng Zhang (CIRA)
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
