Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

["Hollenbeck, Scott" <[e-mail]>]

OK, found it. The thread starts here:

http://www.ietf.org/mail-archive/web/provreg/current/msg01340.html

Summary here:

http://www.ietf.org/mail-archive/web/provreg/current/msg01333.html

Summary: it’s possible for no status values to be returned in an <info> response if the client sending the command isn’t authorized to see the values. Michael was on the right track – thanks.

Scott

From: provreg [mailto:[e-mail]] On Behalf Of Hollenbeck, Scott
Sent: Friday, September 11, 2015 3:34 PM
To: Michael Young
Cc: [e-mail]
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

I’ll do some more digging on Monday. I see where the change was introduced in draft-ietf-provreg-epp-domain-06; -05 said “One or more OPTIONAL <domain:status> elements” in the info response. So yes, this was a deliberate change, but the document author wasn’t considerate enough to keep a change log in the documents… ;)

Scott

From: Michael Young [mailto:[e-mail]]
Sent: Friday, September 11, 2015 3:30 PM
To: Hollenbeck, Scott
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

Scott I’m not sure (long time ago)  but I think it originally had to do with allowing differing levels of detailed response depending on who was asking - hence server policy.  Seems like it got changed in one spot to allow for that but not another.

-Michael Young


On Sep 11, 2015, at 3:20 PM, Hollenbeck, Scott <[e-mail]<mailto:[e-mail]>> wrote:

“Server policy” is a slippery slope when it comes to interoperability. Anyway, I can’t find anything in the email archive that sheds any light on my original question. The text has been consistent since before RFC 3730, so maybe it’s not as confusing as I thought it was this morning.

Scott

From: provreg [mailto:[e-mail]] On Behalf Of Roger D Carney
Sent: Friday, September 11, 2015 2:18 PM
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

+1 Jim, this is how I read it as well and it does make sense to me.  And like Jim, I am not sure why a server would not return the status(es) and we would request that they do, but I do not see a problem with how the RFC is written.


Thanks
Roger


From: provreg [mailto:[e-mail]] On Behalf Of Gould, James
Sent: Friday, September 11, 2015 7:00 AM
To: Hollenbeck, Scott
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [provreg] Inconsistent Domain Status Value Guidance in RFC 5731

Scott,

It doesn’t “tickle any memories”, but making the status optional (“Zero or more OPTIONAL”) in the info response leaves it up to server policy whether or not to return “the at least one associated status value".   It makes sense in describing the statuses in section 2.3 that there must be at least one status, and leave the return of the statuses optional in the info response based on server policy.  I’m not sure why the server would not want to return the statuses, but the protocol supports such a policy.

—

JG

<image001.png>

James Gould
Distinguished Engineer
[e-mail]<x-msg://42/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

On Sep 11, 2015, at 7:28 AM, Hollenbeck, Scott <[e-mail]<mailto:[e-mail]>> wrote:

I received a mail note from someone asking about a difference in the text that appears in RFC 5731 and the schema that is supposed to support that text. First, the text from Section 2.3:

"A domain object MUST always have at least one associated status value".

Text from Section 3.1.2 (info response):

"Zero or more OPTIONAL <domain:status> elements that contain the current status descriptors associated with the domain"

The schema matches the 3.1.2 text. I can't remember why or how we ended up with text that says "MUST always have at least one" in one section and "Zero or more OPTIONAL" in another section. Does this tickle any memories for anyone?

Scott

_______________________________________________
provreg mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/provreg