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

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Do those of you who keep asking about making the <poll> command optional
not know about response code 2101?  From 3730:

'2101    "Unimplemented command"
This response code MUST be returned when a server receives a valid EPP
command element that is not implemented by the server.'

The text in the <poll> description needs to be updated as we've
discussed to note that message queuing isn't required for all command
side effects, but I think you already have what you're asking for.
Don't implement <poll>.  Return 2101 if a client tries to use it.  If at
least two independent implementers don't implement <poll> it can get cut
from the protocol completely as part of the proposed-to-draft process.

BTW, I don't think we should try to mix object-specific data with the
higher-level <poll> elements.  They exist at different layers in the
protocol stack.  We could add an opaque element to the <poll> command to
park object-specific data, but in a sense we already have that
capability with the <extension> element.

-Scott-

> -----Original Message-----
> From: janusz [mailto:janusz@ca.afilias.info] 
> Sent: Monday, August 15, 2005 11:14 AM
> To: Hollenbeck, Scott
> Cc: ietf-provreg@cafax.se
> 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-
> >
> >  
> >
> 
> 
>