Re: [ietf-provreg] Services messages in RFC 3730

[Andrew Sullivan <andrew@ca.afilias.info>]

Hi Scott,

Thanks for your comments.

On Fri, Aug 12, 2005 at 07:06:00AM -0400, Hollenbeck, Scott wrote:
> 
> I don't see how you can interpret the queuing system as optional.  The
> text is completely clear about the need to create and enqueue the
> messages.  "dequeue and deliver messages" does NOT mean "route to
> /dev/null".  It can mean that messages be delivered via email, made
> available for retrieval via ftp, etc.
> 
> "dequeue and deliver".  Not "throw away blindly".

You're right that I'm probably overstating the case.  But consider
cases where the client just doesn't do anything in time for the
notification to have been any use.  For instance, in the ICANN world,
we have 5 days in which a losing registrar may refuse a transfer
(subject to a bunch of policy rules).  If a transfer request message
hasn't been picked up after five days, it's worthless.  Worse, it's
clogging the message queue, and delaying the delivery of other,
potentially useful messages.  The only sane thing to do with such a
message is to throw it away.

As a result of this sort of thing, as near as I can tell, at least
some clients are completely ignoring the poll queue.  We therefore
have to support other kinds of notification mechanisms in parallel to
the poll queue, which is a pointless duplication of effort.  And as
near as I can tell, this is because people find the poll queue less
useful than alternative mechanisms.  I was hoping to make it more
useful.

> What defines "explicitly required", though?  I thought Jim's definition
> was pretty reasonable: if you're a party to a transaction, but not the
> recipient of a response, you get a message.  We can't just limit
> ourselves to transactions that cost money in the ICANN TLD world.

No, I totally agree; and I thought Jim's definition was a good one,
too; I support it.  I absolutely do not want to propose anything that
is restricted to the ICANN TLD world, because I think EPP has lots of
potential outside that world.  In fact, my view is that there are
still some things in the protocol and mapping documents that are too
ICANN-TLD-centric, and turn out to be more policy shaped than
protocol shaped.  (Just so I'm clear: I think that's an accident, and
it's just the result of the collective experience of those who were
working on the original protocol definition at the time the WG was
active.)

> On the priority-based multiple queue thing: priority is relative.  It
> typically either gets ignored or everything becomes "high" priority in

Hrm.  This makes me think that "priority" is an infelicitous word
choice.  What about "facility"?  I'm basically thinking of something
like syslog on UNIX here.  You have some arbitrary tags that tell you
what is generating the message; and that tag allows you to apply
additional rules, depending on the tag.  It's sure useful to
sysadmins; I sort of think it might be useful to clients of a
repository as well.

> someone's eyes.  I don't get a good feeling about adding complexity to
> the mechanism if making it simpler is a viable option.

What about the notion that you could give everything the same
priority (or facility, or whatever we want to call it) value, so that
you'd have something just like the current mechanism?  For that
matter, the attribute could be completely OPTIONAL, and its absense
an indication that the client wants the next message in the queue
regardless of facility.  In that case, those who have implemented the
current mechanism and don't want to do any more work wouldn't have
any work they need to do.

I could be, of course, completely wrong about the utility of a
mechanism like this; I just know that people seem not to be using the
poll queue as I'd like, and I'm trying to figure out how to persuade
them to use it (so I can stop sending reams of email).  

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@ca.afilias.info>                              M2P 2A8
                                        +1 416 646 3304 x4110