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

[janusz <janusz@ca.afilias.info>]

Not implementing <poll> command and returning 2101 looks to me like a 
very problematic implementation option. Section 2.9.3.4 in 3730 ("EPP 
<transfer Command") introduces cases when use of <poll> command seems to 
be mandatory. Also sections 3.2.6 "Offline Review of Requested Actions" 
in 3731, 3732 and 3733 documents introduce  similiar use cases. Only 
registries that don't implement object transfers and pending actions 
could consider the option of not implementing <poll> command.

Changing text of section 2.9.2.3 to make poll message queuing optional 
instead of mandatory should eliminate the issue.

Cheers,

Janusz Sienkiewicz

Hollenbeck, Scott wrote:

>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-
>>>
>>> 
>>>
>>>      
>>>
>>    
>>
>
>  
>