To:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
CC:
ietf-provreg@cafax.se
From:
janusz <janusz@ca.afilias.info>
Date:
Mon, 15 Aug 2005 11:14:26 -0400
In-Reply-To:
<046F43A8D79C794FA4733814869CDF07C92888@dul1wnexmb01.vcorp.ad.vrsn.com>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5
Subject:
Re: [ietf-provreg] 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- > > >