Re: Anyone working on 4310-bis?

On Oct 30, 2009, at 1:27 PM, James Gould wrote:

> “If this "select" solution is taken, I don't mind whether it is  
> implemented via
> elements or attributes.”

I was under the impression that the selectType idea was pretty much  
dead.

>
> Either the elements or attributes will work, but I still like your  
> schema proposal the best.  The key is whether the elements (keyTag,  
> alg, digestType, and digest) are required or optional and if they’re  
> optional what happens if the specified elements match multiple DS  
> records.  I don’t have an issue making them optional as long as the  
> registry returns an error if they match more then one DS record.  I  
> see it as a big issue if the client accidently deletes more then  
> what was desired because they didn’t specify enough unique  
> information.   It’s better to error out and require the client to  
> explicitly specify what they want deleted.

If I once again go back to RFC 5731, I see that non-unique attributes  
of an element that is to be selected for the rem command are  
optional.  If we want to keep the EPP flavor, then I'd suggest that we  
only require the digest itself, and make the others optional.

-Howard

>
>
> -- 
>
>
> JG
>
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> [email protected]
> Direct: 703.948.3271
> Mobile: 703.628.7063
>
>
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> Notice to Recipient:  This e-mail contains confidential, proprietary  
> and/or Registry  Sensitive information intended solely for the  
> recipient and, thus may not be  retransmitted, reproduced or  
> disclosed without the prior written consent of  VeriSign Naming and  
> Directory Services.  If you have received  this e-mail message in  
> error, please notify the sender immediately by  telephone or reply e- 
> mail and destroy the original message without making a  copy.  Thank  
> you.
>
>
> From: Klaus Malorny <[email protected]>
> Date: Fri, 30 Oct 2009 13:30:50 -0400
> To: EPP Provreg <[email protected]>
> Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
>
> On 30/10/09 15:39, Andrew Sullivan wrote:
> > Hi,
>
> Hi Andrew,
>
> >
> > On Fri, Oct 30, 2009 at 12:39:00PM +0100, Klaus Malorny wrote:
> >
> >[...]
> >> 2) there is a consensus that<add>  and<rem>  elements shall be  
> allowed in
> >> a single request, which must be on the other hand mutually  
> exclusive to
> >> the<chg>  element.
> >
> > Are we sure that the<add>  and<rem>  elements have to be processed  
> in
> > the order in which they appear?  I am not completely sure.  I recall
> > at least one operator who had an issue related to this
> > processing-order question.  If they do _not_ have to be so  
> processed,
> > then in fact they can't be allowed in a single request because the
> > effect could be different from what is intended.  (Note that this
> > remark also means that there is by no means a consensus on this  
> matter
> > yet.)
> >
> > [...]
>
> This problem has always been the case with EPP. If I submit a domain  
> update
> request with adding the status "clientHold" and removing the status  
> "clientHold"
> at the same time, what is the outcome? This applies to contacts,  
> name servers
> and other stuff as well.
>
> So the protocol should clearly say how such a situation shall be  
> handled:
> - define a static execution order, e.g. first the removal, then the  
> addition
> - declare this as ambiguous and reject the order
> - declare this as a non-change and ignore
>
> By the way, as there seems to be some confusion: IMHO the order in  
> the XML
> document should *never* imply any order of execution.
>
> >
> > Not elements, but attributes, is the way I've got it at the  
> moment.  I
> > didn't include the attributes other than the hash in the text as  
> it's
> > written, but I think James has convinced me there'd be no harm in
> > adding the other ones.
>
> If this "select" solution is taken, I don't mind whether it is  
> implemented via
> elements or attributes.
>
> Regards,
>
> Klaus
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 
> =-=-=-
> List run by majordomo software.  For (Un-)subscription and similar  
> details
> send "help" to [email protected]
>
>