[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Howard Eland <heland@afilias.info>, EPP Provreg <ietf-provreg@cafax.se>
From: James Gould <jgould@verisign.com>
Date: Thu, 29 Oct 2009 15:52:27 -0400
In-Reply-To: <99363757-F0D1-47F8-ADA5-75FE9247FD27@afilias.info>
Sender: owner-ietf-provreg@cafax.se
Thread-Index: AcpYvFjWOzzp1P4pR8ynFZ7dirnNPQAFP5/r
Thread-Topic: [ietf-provreg] Anyone working on 4310-bis?
User-Agent: Microsoft-Entourage/12.20.0.090605
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

Title: Re: [ietf-provreg] Anyone working on 4310-bis?
“One thing that does make using all four elements easier: it's
consistent with both the add and chg operators, which may make it
easier for implementors to code (well, a tiny bit, anyway).  James,
I'm not sure if this is to your point or not”

Yes, using all four elements makes it consistent with the add and chg.  The rem could make some if not all of the 4 elements optional, but I’m not sure if this make things simpler or more complex for the client.

“Codifying the edge cases is important, however, and it appears that
we'll have to lose some of this compatibility to do so (regardless if
we use just the hash on the rem, or the entire dsData).  By requiring
anything other than just the keyTag itself, it will not be backwards
compatible for implementors - today, the keytag submission is
sufficient, tomorrow, it will not be (going strictly by the RFC, not
by registry policy).”

Yes, the backwards compatibility would only be at the XML schema level.  This should be a reasonable compromise.  



--


JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
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: Howard Eland <heland@afilias.info>
Date: Thu, 29 Oct 2009 13:05:57 -0400
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?

One thing that does make using all four elements easier: it's
consistent with both the add and chg operators, which may make it
easier for implementors to code (well, a tiny bit, anyway).  James,
I'm not sure if this is to your point or not.

Codifying the edge cases is important, however, and it appears that
we'll have to lose some of this compatibility to do so (regardless if
we use just the hash on the rem, or the entire dsData).  By requiring
anything other than just the keyTag itself, it will not be backwards
compatible for implementors - today, the keytag submission is
sufficient, tomorrow, it will not be (going strictly by the RFC, not
by registry policy).

I am no longer particular to either method - they both would be fine.

-Howard

On Oct 29, 2009, at 10:57 AM, Howard Eland wrote:

> This is what I was saying.  The digest is unique (specially when
> we're talking across only the same keytag), so the rest of the
> information is superfluous.
>
> -Howard
>
> On Oct 29, 2009, at 10:32 AM, Andrew Sullivan wrote:
>
>> On Wed, Oct 28, 2009 at 10:32:19AM -0400, James Gould wrote:
>>
>>> still behaves like a replace, which again is backward compatible.  
>>> The only
>>> difference is that all four elements need to be provided (keyTag,
>>> alg,
>>> digestType, digest) with a rem, which I don’t believe should be a
>>> big issue.
>>> Does anyone see an issue with having to specify either the keyTag
>>> or all
>>> four elements on a rem?
>>
>> Can you say why you prefer to use all four elements instead of just
>> the digest?  The digest actually is unique, so adding the other
>> elements doesn't make it easier, I don't think, does it?
>>
>> A
>>
>>
>> --
>> Andrew Sullivan
>> ajs@shinkuro.com
>> Shinkuro, Inc.
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> =-=-=-=-
>> List run by majordomo software.  For (Un-)subscription and similar
>> details
>> send "help" to ietf-provreg-request@cafax.se
>>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-
> List run by majordomo software.  For (Un-)subscription and similar
> details
> send "help" to ietf-provreg-request@cafax.se
>


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se



Home | Date list | Subject list