Subject: Re: [regext] EPP extension to take in generic key value pairs

From: "Gould, James" <[email-masked]>
Date: Tue, 25 Apr 2017 17:36:05 +0000

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

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

From: Tongfeng Zhang <[email-masked]>
Date: Tuesday, April 25, 2017 at 11:40 AM
To: James Gould <[email-masked]>, "[email-masked]" <[email-masked]>
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:[email-masked]]
Sent: Wednesday, April 19, 2017 2:38 PM
To: Tongfeng Zhang; [email-masked]
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

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

From: regext <[email-masked]<mailto:[email-masked]>> on behalf of Tongfeng Zhang <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 19, 2017 at 1:22 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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)

---

From: Tongfeng Zhang <[email-masked]>
Date: Tue, 25 Apr 2017 18:56:49 +0000

I absolutely agree with you that the generic extension cannot be a complete solution to any problem.

What I’m looking at is that it can be part of the solution. And the reason I see value in this is that it can keep the XML schema lighter weighted comparing to always adding a new extension.

Tongfeng

From: Gould, James [mailto:[email-masked]]
Sent: Tuesday, April 25, 2017 1:36 PM
To: Tongfeng Zhang; [email-masked]
Subject: Re: [regext] EPP extension to take in generic key value pairs

Hi,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

From: Tongfeng Zhang <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 25, 2017 at 11:40 AM
To: James Gould <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] RE: [regext] EPP extension to take in generic key value pairs

Thanks,
Tongfeng

From: Gould, James [mailto:[email-masked]]
Sent: Wednesday, April 19, 2017 2:38 PM
To: Tongfeng Zhang; [email-masked]<mailto:[email-masked]>
Subject: Re: [regext] EPP extension to take in generic key value pairs

Hi,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Dear colleagues,

Thanks,
Tongfeng Zhang  (CIRA)

---

From: "Francisco Obispo" <[email-masked]>
Date: Tue, 25 Apr 2017 11:22:31 -0700

+1

I agree with this view.

In my opinion, the use of a generic extension for KV pairs, defeats the 
purpose of using XML/XSD

I think Neustar has a KV pair extension, for .US, perhaps others might 
be tempted to do the same. But in reality, the fact that the XML is 
verbose on the data, combined with the XML Schema tools to validate the 
structures makes it a very valuable tool when implementing extensions.

So it may seem like having a *generic* way of passing data around is 
convenient enough, but when you add the overhead of having to unmarshall 
and validate data manually, then the benefit of using the XML/XSD 
becomes obvious.

Best regards,

On 25 Apr 2017, at 10:36, Gould, James wrote:

> 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)?
>
> c.       Is the language used for other purposes like translation or 
> transliteration and if so which contact fields?
>
> 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?
>
> 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
>
>
> James Gould
> Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> 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
>
>
> 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
>
>
> James Gould
> Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> From: regext <[email-masked]<mailto:[email-masked]>> 
> on behalf of Tongfeng Zhang 
> <[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext