Re: EPP Poll 'msgid' attribute

On Mon, Oct 31, 2011 at 10:19 PM, Hollenbeck, Scott <
[email protected]> wrote:

> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On
> > Behalf Of Mike O'Connell
> > Sent: Monday, October 31, 2011 5:33 AM
> > To: [email protected]
> > Subject: [provreg] EPP Poll 'msgid' attribute
> >
> > 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.
> >
>

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.



> > Has anyone implemented anything like this? What are the thoughts
> > regarding this?
>
> 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

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg