Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt

["Ning Kong" <[e-mail]>]

Hi Patrick,

> Thanks for this, Ning.
My pleasure.

> I have some comments regarding  3.3.1. Objects in the Contact Response
> 
> Say  the registry  has a policy that does not allow the display of all or
part of
> the contact info to the querying party We could either
> 
> - not return the corresponding field
> - return the field name, but with an empty value
> - return the field name, and a field value that could be either
>          - a text string saying the value cannot be displayed by policy,
> whose content is up to the registry operator
>          - a return code, sort of like HTTP 401  that would indicate the
> querying party  is not authorized to view that information.
I think you put forward a general issue. IMO, the HTTP draft
(draft-designteam-weirds-using-http-00) as the common infrastructure
document is suitable to cover this point. For example, a new section (e.g.
5.5 Unauthorized Answers) may be added to propose the corresponding response
mechanisms.
BTW, I think another optional response which might also be considered for
this scenario is that returning not only the field name and a text saying
the querying party is not authorized, but also a reference to tell the
requester how to acquire the authorized answers. Through this reference, if
the requester can meet the corresponding requirements (e.g. providing
correct authentication info or a token authorized by the owner), he/she can
further acquire the authorized answers. To consider this kind of response,
the authentication mechanism of RESTful WHOIS services needs to be
correspondingly designed.

> As for the fields themselves, it has been pointed out that telefax numbers
are
> of little use these days, and that other channels of communications may be
> more responsive.  Facebook and Twitter come to mind.  However, these
> type of services come and go,. They might be out of fashion by the time
the
> work of this WG gets actually deployed.
So, I wonder whether we should consider discarding some traditional WHOIS
data elements or adopting some new fashionable ones (e.g. IM, SNS) as basic
fields.

> There should be a mechanism that allows for the extension of the contact
> information, without requiring an update the corresponding RFCs.
We have the extension interface in the draft. Do you think this can meet the
above requirement?

Cheers,
Ning