Subject: [eppext] EPP service message extension

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 23 Oct 2014 16:14:53 +0000

All,

i've just posted a first version of the description of our EPP service message extension. I'm aiming at registering that extension with the hopefully-soon-to-be EPP Extensions Registry, and therefore i do believe it is of interest to the group. The document defines the state of the extension as it is currently deployed (including the shady legacy corners), rather than defining a "nice to have" structure. The extension is also contained in the Net::DRI Perl EPP client toolkit.

I'm happy to present that draft during the upcoming meeting, if the chairs can spare a time slot. WG adoption is *not* my goal, since this document wouldn't be covered by the current charter anyways. Feedback is, however, of course appreciated :)

Here's the announcement:

A new version of I-D, draft-mayrhofer-eppext-servicemessage-00.txt
has been successfully submitted by A. Mayrhofer and posted to the IETF repository.

Name:		draft-mayrhofer-eppext-servicemessage
Revision:	00
Title:		EPP Service Messages Extension
Document date:	2014-10-23
Group:		Individual Submission
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-mayrhofer-eppext-servicemessage-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mayrhofer-eppext-servicemessage/
Htmlized:       http://tools.ietf.org/html/draft-mayrhofer-eppext-servicemessage-00

thanks,
Alex

---

From: Gavin Brown <[email-masked]>
Date: Mon, 27 Oct 2014 18:02:25 +0000

Hi Alexander,

I've reviewed this draft. It addresses a pressing issue which a lot of
registrars want to see resolved.

My initial concern is that your draft is too flexible. There is a fine
balance to be struck between being flexible enough to allow for a
variety of different business rules, and being so flexible that you end
up with wildly different (and non-interoperable) implementations. There
are a few things that I think you could do to tighten up the specification:

* the list of events which would trigger a message should be enumerated,
and a unique token for each be included in the schema. I am sure that
this mailing list could produce an almost comprehensive list of such events.

So the synax would look like this:

<message xmlns="http://tld-box.at/xmlns/resdata-1.0">
  <type>transferApproved</type>
  <!-- ... -->
</message>

Events that are not covered by this list could be handled using a
"custom" value with an optional attribute, like so:

<message xmlns="http://tld-box.at/xmlns/resdata-1.0">
  <type name="somethingCustom">custom</type>
  <!-- ... -->
</message>

* require that all messages have a timestamp, like so:

<message xmlns="http://tld-box.at/xmlns/resdata-1.0">
  <type>transferApproved</type>
  <eventDate>2014-10-27T17:48:21.0Z</eventDate>
  <!-- ... -->
</message>

* require that all messages be associated with a single object in the
repository. The object should be specified by its namespace, and its
unique identifier (and optionally ROID), for example:

<message xmlns="http://tld-box.at/xmlns/resdata-1.0">
  <type>transferApproved</type>
  <eventDate>2014-10-27T17:48:21.0Z</eventDate>
  <desc>Inbound transfer of test.example was APPROVED.
    Subordinate hosts ns1.test.example, ns2.test.example were
    also transferred.</desc>
  <object>
    <objURI>urn:ietf:params:xml:ns:host-1.0</objURI>
    <objID>ns1.text.example</objID>
    <objROID>hostroid-1</objROID>
  </object>
</message>

If an event affects multiple objects, queue multiple messages.

* Where an event has resulted in a change to the attributes of an
object, it should be possible to include a partial <info> response in
the message, containing the changed object attributes (plus the minimum
necessary elements to allow the element to validate against the schema),
like so:

<message xmlns="http://tld-box.at/xmlns/resdata-1.0">
  <type>transferApproved</type>
  <eventDate>2014-10-27T17:48:21.0Z</eventDate>
  <desc>Inbound transfer of test.example was APPROVED.
    Subordinate hosts ns1.test.example, ns2.test.example were
    also transferred.</desc>
  <object>
    <objURI>urn:ietf:params:xml:ns:host-1.0</objURI>
    <objID>ns1.test.example</objID>
    <objInfo xmlns:host="urn:ietf:params:xml:ns:host-1.0">
      <host:name>ns1.test.example</host:name>
      <host:roid>hostroid-1</host:roid>
      <!-- ... -->
    </objInfo>
  </object>
</message>

G.

On 23/10/2014 17:14, Alexander Mayrhofer wrote:
> _______________________________________________
> EppExt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eppext
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 30 Oct 2014 10:56:28 +0000

Gavin,

thanks for the review... This is definitely much appreciated - more inline:

> I've reviewed this draft. It addresses a pressing issue which a lot of registrars
> want to see resolved.
>
> My initial concern is that your draft is too flexible. There is a fine balance to
> be struck between being flexible enough to allow for a variety of different
> business rules, and being so flexible that you end up with wildly different
> (and non-interoperable) implementations. There are a few things that I think
> you could do to tighten up the specification:

I do certainly agree. When i wrote the draft, i had the choice between "document what's there, and take the blame", or "specify what you wish would be there". I chose documenting the existing extension, since it's deployed in production, and - as you know - shifting that towards a "nice to have" version of it is significant effort on both sides of the EPP connection..

We're all tempted to improve things as soon as we see them, but it's a good question whether the EPP Extensions Registry should take "documentation of existing things" or "clean slate" specifications. Both have valid reasons.

But, yes, of course i do appreciate your feedback on the structure of the extension - just not sure what direction to take with the draft - ultimately, i would probably need to create two drafts, one for the currently existing extension, and one for the "nice to have" schema  :)

> and a unique token for each be included in the schema. I am sure that this
> mailing list could produce an almost comprehensive list of such events.

There's a list of events that we use, some are contained in the examples. Some are pretty generic, while some are very specific to some of our policies... For example:

ContactStatusSet              
ContactStatusUnset            
DelegationDelete              
HasExpired                    
LowCredit                     
URSLocked                     
NoCredit                      
...

> Events that are not covered by this list could be handled using a "custom"
> value with an optional attribute, like so:
> 

Understood... Well, an alternative to that would be to create an IANA registry for the event type (... not sure that's worth the effort), and use first come first served as policy... But using a "custom" type would also work... I'm a bit reluctant about switching from attribute to element for the "type" information, but of course it makes sense for "more specific" information... a pair of attributes could also work..

>   <eventDate>2014-10-27T17:48:21.0Z</eventDate>

Good point. I need to doublecheck whether our assumption was that there's enough timestamping information in the rest of the EPP frame already.

> repository. The object should be specified by its namespace, and its unique
> identifier (and optionally ROID), for example:
 
>     <objROID>hostroid-1</objROID>

There's *some* kind of relation mechanism in use by including "<data> <entry type='domain'>..." elements into the message, but of course it's very much "free form" information - yes, the proposal above is really nice, will have to think about implications on current implementations and 

> If an event affects multiple objects, queue multiple messages.

Hmm... Some of the events (particularly the "WillExpire" type) contains lists with hundreds of domains, and in such cases i would rather not want to queue that many messages for the registrar. However, i don't see why the "object" element you proposed above couldn't be 0..n, this wouldwork perfectly well in that use case.
 
> * Where an event has resulted in a change to the attributes of an object, it
> should be possible to include a partial <info> response in the message,
> containing the changed object attributes (plus the minimum necessary
> elements to allow the element to validate against the schema), like so:
> 

Good idea, too... Yes, in many cases the "resonponse frame" is pretty useless in such situations, so inclusion of an "info" frame (or specifically, the "infData" element, probably) would work quite well here..

Exciting ideas - I need to think and discuss those internally...!

Alex