Re: Services messages in RFC 3730

I see one more issue with <poll> command.

The mandatory protocol behavior appears to be inconsistent with 
reasonable levels of interoperability.

The XML syntax of <poll> response lacks elements that allow returning 
basic object-specific information such as name and ROID for actions such 
as auto-renewals or deletion and doing so in an interoperable manner. At 
the same time, the specification appears to make it mandatory for the 
server to produce <poll> service messages for such actions.  In 
practice, that implies that server implementors will be forced to either:

-produce generic service messages that will lack object specific 
information and hence will be nearly meaningless for the client
 OR
- use extensions or include object information into message text to make 
the service messages meaningful, but at the cost of interoperability and 
registrar code that is registry/server independent.

I can see 2 ways of solving the conflict.

1. Making poll command OPTIONAL as it was defined in earlier EPP draft 
documents.
2. Adding additional elements to <poll> response for returning basic 
object-specific information.

Option 1 offers no impact on existing EPP deployments.
Option 2 would impact existing EPP deployments but in the long term it 
would give more flexibility to client and server implementers. Basic 
object-information could be even used to prioritize dequeuing items from 
poll queues.

Cheers,

Janusz Sienkiewicz



Hollenbeck, Scott wrote:

>Superlatives and astonishment aside, there are really three issues here:
>
>1. Is priority-based messaging needed?  You obviously think so assuming
>that messaging isn't optional, so let's continue.
>
>2. If so, is this a specification issue or an implementation detail?  I
>believe it's both.
>
>Implementation detail: how you implement your message queuing system is
>up to you.  You might have three queues instead of one, with "high
>priority" messages going into one queue, "normal priority" messages
>going into a second queue, and "low priority" messages going into a
>third.  As registry operator you make an implementation decision to
>determine which messages go where.  The <poll> command can then be
>implemented to read from them in whatever order makes sense to you.
>
>Specification issue: if multiple queues are implemented, how does one
>let the client deal with that fact?  As is, they could be read from in
>whatever order the server operator decides to impose on the reader.
>That's probably not too helpful.  We also need to look at loosening up
>the text as Jim suggested.
>
>3. If a specification issue, should something new be added to the core
>specs or should something new be defined in an extension?  Given that
>we're talking about adding a new feature that may or may not be useful
>to everyone (as you say, "it should all be OPTIONAL"), documenting a new
>feature (adding priority marks to messages and allowing a client to
>specify how they wish to deal with the priorities) in a standard
>extension seems like the least intrusive way to make the functionality
>available for these reasons:
>
>a. It truly is optional.
>b. It doesn't complicate other existing implementations.
>c. It's common IETF practice to add new features via extensions once
>proposed standards are published.  Extension development is usually a
>good reason to spin up a new working group.
>d. It allows us to avoid a core schema change and the resulting new
>protocol version.
>
>Think about d. for a moment.  A protocol version rev likely implies an
>operational requirement for ALL conforming servers and clients to
>support both old and new versions for some TBD period of time.  An
>extension can be deployed without introducing version management issues.
>
>-Scott-
>
>  
>