Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 28 Oct 2014 16:14:03 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-weirds-rdap-query-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

= Section 3.2.3 =
If I'm reading the document correctly, when searching for an entity, the
search pattern is expected to represent an entity using the syntax
specified in Section 6.1 of draft-ietf-weirds-json-response. But when the
path segment is provided, rather than a search, Section 3.1.5 says this:

   The <handle> parameter represents an entity (such as a contact,
   registrant, or registrar) identifier whose syntax is specific to the
   registration provider.  For example, for some DNRs contact
   identifiers are specified in RFC 5730 [RFC5730] and RFC 5733
   [RFC5733].

This makes it seem as if an entity in a path segment uses different
syntax (actually, non-standard syntax that is up to the registration
provider) than an entity that someone might search for. Is there some
specific field in the entity definition in
draft-ietf-weirds-json-response that <handle> is supposed to correspond
to? Aren't HTTP GETs for both path segments and searches meant to provide
responses based on the same underlying data? If so, I don't understand
why there is a specified syntax for entities in one but not the other.
This also seems inconsistent with the following text in Section 6.1 of
draft-ietf-weirds-json-response:

   The entity object class appears throughout this document and is an
   appropriate response for the /entity/XXXX query defined in
   Registration Data Access Protocol Lookup Format
   [I-D.ietf-weirds-rdap-query]

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 3 =
"The query URL is
   constructed by concatenating the base URL to the help path segment
   specified in either Section 3.1.6."

The "either" is extraneous, or there is some other section missing at the
end of this sentence.

= Section 4.2 and Section 8:
I think it would be helpful here to point out that the
identity/authorization of the searcher may be a relevant factor in
determining how broad the response set should be for any particular query
(and not just a single static policy that applies to all searchers
equally).

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 29 Oct 2014 13:04:54 +0000

> -----Original Message-----
> From: weirds [mailto:[email-masked]] On Behalf Of Alissa
> Cooper
> Sent: Tuesday, October 28, 2014 7:14 PM
> To: The IESG
> Cc: [email-masked]; [email-masked]; draft-ietf-weirds-
> [email-masked]
> Subject: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-
> query-16: (with DISCUSS and COMMENT)
> 

It's actually Section 5.1 of json-response. That section reference is incorrect (and could be removed as suggested below). If only xml2rfc made it possible to tag cross-document section references...

The json-response document doesn't actually provide a syntax specification for entity handles. The closest it comes is "a string representing an registry unique identifier of the entity" (we need to change "an registry" to "a registry"). The text in 3.2.3 (Entity Search) should be consistent with 3.1.5 (Entity Path Segment Specification) and json-response. 3.1.5 says this:

"The <handle> parameter represents an entity (such as a contact, registrant, or registrar) identifier whose syntax is specific to the registration provider."

This is consistent with json-response. Would this change in 3.2.3 address your concern?

OLD
"where XXXX is a search pattern representing an entity name as specified in Section 6.1 of [I-D.ietf-weirds-json-response]"

NEW
"where XXXX is a search pattern representing an entity (such as a contact, registrant, or registrar) identifier whose syntax is specific to the registration provider"

"either" should be removed. Thanks for that catch.

> (and not just a single static policy that applies to all searchers

I can add this to both sections:

"Note that there might not be a single, static information return policy that applies to all clients equally. Client identity and associated authorizations can be a relevant factor in determining how broad the response set will be for any particular query."

Does that work?

Scott

---

From: Pete Resnick <[email-masked]>
Date: Wed, 29 Oct 2014 08:32:18 -0500

On 10/29/14 8:04 AM, Hollenbeck, Scott wrote:
> If only xml2rfc made it possible to tag cross-document section references...
>    

Actually, it does. Make sure there's an "anchor" on the section, and 
then use an <xref target="anchorname" /> where you want the reference.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Oct 2014 09:36:04 -0400

\>> If only xml2rfc made it possible to tag cross-document section
>> references...
>
> Actually, it does. Make sure there's an "anchor" on the section, and then
> use an <xref target="anchorname" /> where you want the reference.

That doesn't work if the section you're citing is in another document.

Barry

---

From: Pete Resnick <[email-masked]>
Date: Wed, 29 Oct 2014 08:37:22 -0500

On 10/29/14 8:36 AM, Barry Leiba wrote:
>> use an<xref target="anchorname" />  where you want the reference.
>>      

Darn it. "Cross-document". Reading...not my strong suit.

pr

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 29 Oct 2014 14:19:22 +0000

> From: Pete Resnick [mailto:[email-masked]]
> Sent: Wednesday, October 29, 2014 9:32 AM
> To: Hollenbeck, Scott
> Cc: Alissa Cooper; The IESG; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-
> rdap-query-16: (with DISCUSS and COMMENT)
> 

That works *within* the document, not in a second document.

Scott

---

From: Andy Newton <[email-masked]>
Date: Thu, 30 Oct 2014 11:44:27 +0000

On Oct 29, 2014, at 9:04 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

= Section 3.2.3 =
If I'm reading the document correctly, when searching for an entity,
the
search pattern is expected to represent an entity using the syntax
specified in Section 6.1 of draft-ietf-weirds-json-response. But when
the
path segment is provided, rather than a search, Section 3.1.5 says
this:

to? Aren't HTTP GETs for both path segments and searches meant to
provide

Alissa, I do not fully comprehend this issue. To answer your question: yes the HTTP GETs for both lookups and searches of entities are suppose to return the same underlying data. Would it be helpful for the text in json-response above to also state they are applicable for searches?

OLD

NEW

Scott, I am confused. One is a search by handle and the other a search by a person or organization’s name. Doesn’t this eliminate the name search?

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 30 Oct 2014 12:03:14 +0000

From: Andy Newton [mailto:[email-masked]]
Sent: Thursday, October 30, 2014 7:44 AM
To: Hollenbeck, Scott; Alissa Cooper
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT)

= Section 3.2.3 =

OLD

NEW

Scott, I am confused. One is a search by handle and the other a search by a person or organization's name. Doesn't this eliminate the name search?

[SAH] I thought the comment had to do with lookups by entity handle (3.1.5) and searches by entity handle (3.2.3). The text in the two sections describes handle syntax inconsistently. That's what I attempted to correct.

Scott

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 30 Oct 2014 07:21:41 -0700

On Oct 29, 2014, at 6:04 AM, Hollenbeck, Scott <[email-masked]> wrote:

> "where XXXX is a search pattern representing an entity (such as a contact, registrant, or registrar) identifier whose syntax is specific to the registration provider”

Yes, this addresses my concern, assuming it works for Andy.

> "Note that there might not be a single, static information return policy that applies to all clients equally. Client identity and associated authorizations can be a relevant factor in determining h…

Yes, sounds good.

Thanks,
Alissa

---

From: Andy Newton <[email-masked]>
Date: Thu, 30 Oct 2014 15:06:12 +0000

On Oct 30, 2014, at 8:03 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

OLD

NEW

[SAH] I thought the comment had to do with lookups by entity handle (3.1.5) and searches by entity handle (3.2.3). The text in the two sections describes handle syntax inconsistently. That’s what I attempted to correct.

So the old is?

  where XXXX is a search pattern representing an entity handle as
  specified in Section 6.1 ...

Note s/handle/name/.

If so, I get it.

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 30 Oct 2014 15:23:30 +0000

From: Andy Newton [mailto:[email-masked]]
Sent: Thursday, October 30, 2014 11:06 AM
To: Hollenbeck, Scott
Cc: Alissa Cooper; The IESG; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [weirds] Alissa Cooper's Discuss on draft-ietf-weirds-rdap-query-16: (with DISCUSS and COMMENT)

OLD

NEW

So the old is?

Note s/handle/name/.

If so, I get it.

-andy
[SAH] Ah, OK, yes, it would be better to say "entity handle" in the two places where we're talking about handles. 3.2.3 also describes search by entity name. I see what broke here...

The text in 3.2.2 that describes a search by entity name refers to what used to be in Section 6.1 of json-response. The old text isn't there anymore. What we want now is described in 5.1, but it's now part of the vcard in the vcardArray. We need to refer to either the FN property or the N property. I *think* FN is more appropriate - right?