Re: [eppext] EPP service message extension

[Michael Holloway <[e-mail]>]

Hi Alexander

Agreed this is in principle a good idea! But like Gavin, I am a little 
concerned that its too flexible - so just wanted to add a couple of 
points here.

I think it is key that each message should be related to a single object 
where possible (e.g. not a Registrar object). In a case where a registry 
wanted to sent a message similar to HasExpired in the draft, they could 
potentially have multiple dates and multiple domains in the same 
message, leading to confusion about which domain are expiring on which 
date. Given the draft doesn't specify "how" to do this, we could end up 
with a little guess work.

<data>
      <entry name="date">2016-02-25</entry>
      <entry name="domain">test-expire1.example</entry>
      <entry name="date">2016-02-27</entry>
      <entry name="domain">test-expire2.example</entry>
      <entry name="domain">test-expire3.example</entry>
</data>



This draft also means that we have to always assume that there are (or 
can be) multiple entry elements with the same name (and treat it as an 
array) - which feels like it can spiral into a multi-multi relationship 
of untyped elements. We know a domain can have multiple statuses, but it 
cannot have multiple expiry dates. Registrar software will need to 
figure what's being sent and still check for multiple expiry dates (and 
what would we do with that?:) . I think in the end each message handler 
will need to be coded by the registrar software because its too untyped 
to handle so the flexibility means that its not really simplifying or 
even standardising the notifications much.

I might have be able to provide more useful input after having a look at 
in action. This doesn't seems to be on the CPAN version of Net-DRI (or 
did I miss it?). Do you have a link to the latest TLDBox version?  I am 
pro standardisation so would be happy to look and give some input!

Cheers,
Michael


*Michael Holloway
Senior Systems Administrator**| Com Laude*
2^nd Floor, 28-30 Little Russell Street
London, WC1A 2HN, United Kingdom

[e-mail] <mailto:[e-mail]>
www.comlaude.com <http://www.comlaude.com>



On 27.10.2014 19:02, Gavin Brown wrote:
> 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:
>> 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
>>
>> _______________________________________________
>> EppExt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/eppext
>>
>
>
> _______________________________________________
> EppExt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eppext