Subject: [provreg] EPP Poll 'msgid' attribute

From: Mike O'Connell <[email-masked]>
Date: Mon, 31 Oct 2011 11:33:19 +0200

Hi All

We're currently implementing an EPP based registry.

One of our test registrars pointed out something of interest which I thought should be mentioned in the spec.

The EPP schema element for 'poll' requests allows for two attributes 'op' and 'msgid'. The spec states that when op='req' is used the server should return an unacked item from the FIFO queue, and that when op='ack' is used you need to specify the 'msgid' to acknowledge.

We're looking at implementing a selectable poll message process where the op='req' can specify the clTRID as the 'msgid' attribute to retrieve any unacked responses associated with that client identifier.

Has anyone implemented anything like this? What are the thoughts regarding this?

Kind Regards,

Mike O'Connell
Domain Name Services

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 31 Oct 2011 11:19:07 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mike O'Connell
> Sent: Monday, October 31, 2011 5:33 AM
> To: [email-masked]
> Subject: [provreg] EPP Poll 'msgid' attribute
> 
> Hi All
> 
> 
> The EPP schema element for 'poll' requests allows for two attributes
> 'op' and 'msgid'. The spec states that when op='req' is used the server
> should return an unacked item from the FIFO queue, and that when
> op='ack' is used you need to specify the 'msgid' to acknowledge.
> 
> We're looking at implementing a selectable poll message process where
> the op='req' can specify the clTRID as the 'msgid' attribute to
> retrieve any unacked responses associated with that client identifier.
> 

I personally think you're better off following the spec. One-off deviations make it more difficult for registrars to develop software systems that work across registries. You might want to check with your other registrar partners to see what they think.

Having said that, if you do it be sure to change the URIs for the namespace and schema identifiers. Once you change the schema you're (as you described above) EPP-based, not EPP.

Scott

---

From: Wil Tan <[email-masked]>
Date: Mon, 31 Oct 2011 22:23:23 +1100

> > retrieve any unacked responses associated with that client identifier.

Not sure I understand you correctly, but I presume your intention is to
allow a registrar to skip the head of the queue while reading messages off
the poll queue.

Piggybacking on clTRID sounds like a bad idea.

If you had to do it, the "msgID" attribute would be a better place as it's
not used when op="req". While specifying a "msgID" with op="req" is not
explicitly forbidden by RFC 5730, it's still a hack.

You'd still have to solve the problem of the registrar needing to discover
the message IDs after the head of the queue, except in the special case of
monotonically increasing msgID's, but msgID is of type xsd:token and so
isn't is pretty much up to server implementation.

> I personally think you're better off following the spec. One-off
> deviations make it more difficult for registrars to develop software
> systems that work across registries. You might want to check with your
> other registrar partners to see what they think.
>
> Having said that, if you do it be sure to change the URIs for the
> namespace and schema identifiers. Once you change the schema you're (as you
> described above) EPP-based, not EPP.
>
>
Rather than changing the namespace URI on the entire core EPP schema, you
could create an extension command and use that instead of the standard
<poll>.

If you do that, I'd urge you to write an I-D as others may be interested in
this work as well, and it'll go a long way towards interoperability.

.wil

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Oct 2011 09:42:40 -0400

> Has anyone implemented anything like this? What are the thoughts regarding this?

I argued for altering the way poll worked to do something quite like
this, about the time that EPP went through one of the standards levels
(I think from proposed to draft).  I outlined the suggestion in a
long-expired I-D that is still available:
http://tools.ietf.org/id/draft-sullivan-epp-experience-00.txt.  See
sections 3.4 and 4.2.

I strongly recommend you not try to shoehorn this functionality into
the existing poll queue mechanism.  The existing mechanism is quite
clearly FIFO, and if you try to manage it differently while using the
same syntax, you not only produce quite different behaviour with the
same protocol; you'll also find that you don't have enough primitives
to manage the queue correctly, and messages will get lost.  Anyway,
you'll be in flagrant violation of section 2.9.2.3 of RFC 5730: "a
successful response to a <poll> command MUST return the first message
from the message queue."  If conformance is important to you for
contractual reasons, then you just can't do this.

When I argued in favour of the approach to the poll queue I outlined
in that I-D, Scott Hollenbeck pointed out (correctly) that you could
do it with an extension anyway.  That's what I'd recommend.  Afilias
never did undertake that work, however, because a colleague of mine in
the development department decided instead that the passage, "Service
messages SHOULD be created for passive clients affected by an action
on an object," used the ordinary English meaning of SHOULD and not the
RFC 2119 one.  (Note that in RFC 3730, that SHOULD was a MUST, but I
still don't see how the SHOULD gets one off the hook in case it's
merely convenient.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 31 Oct 2011 13:51:35 +0000

Mike,

If you are creating a different type of queue that is not FIFO I suggest
that you create a new object mapping (e.g. Selectable Queue Object
Mapping) that would provide the interface that you're looking for and to
keep the FIFO queue support as defined by RFC 5730.  Changing the
semantics of existing mature interfaces for a new purpose would be an
interoperability issue that is highly discouraged.

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

On 10/31/11 5:33 AM, "Mike O'Connell" <[email-masked]> wrote:

>The EPP schema element for 'poll' requests allows for two attributes 'op'
>and 'msgid'. The spec states that when op='req' is used the server should
>return an unacked item from the FIFO queue, and that when op='ack' is
>used you need to specify the 'msgid' to acknowledge.
>
>We're looking at implementing a selectable poll message process where the
>op='req' can specify the clTRID as the 'msgid' attribute to retrieve any
>unacked responses associated with that client identifier.
>
>_______________________________________________
>provreg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/provreg

---

From: Mike O'Connell <[email-masked]>
Date: Mon, 31 Oct 2011 16:15:10 +0200

Hi James,

Just to clarify the idea here is not to replace the FIFO queue, but merely supplement the poll request by allowing the registrar to retrieve a pending action response to a specific client message identifier (clTRID). That way the registrar doesn't have to sift through dozens or even hundreds of pending poll messages to get to what he wants/needs.

This functionality would be completely optional but still fully compliant with the default EPP schema, and it assumes the registrar maintains his clTRID values.

Thank you for the responses.

Kind Regards,

Mike O'Connell
Domain Name Services

---

From: "Gould, James" <[email-masked]>
Date: Mon, 31 Oct 2011 14:40:02 +0000

Mike,

It is good that you make it backward compatible; although it would not be
an RFC compliant addition.  Has any registrar explicitly asked for such a
feature?  Why wouldn't you use the svTRID since it would be guaranteed to
be unique?  What would happen if the client sent you a duplicate clTRID?

--

JG

James Gould

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

On 10/31/11 10:15 AM, "Mike O'Connell" <[email-masked]> wrote:

>Hi James,
>
>
>Just to clarify the idea here is not to replace the FIFO queue, but
>merely supplement the poll request by allowing the registrar to retrieve
>a pending action response to a specific client message identifier
>(clTRID). That way the registrar doesn't have to sift through dozens or
>even hundreds of pending poll messages to get to what he wants/needs.
>
>This functionality would be completely optional but still fully compliant
>with the default EPP schema, and it assumes the registrar maintains his
>clTRID values.
>