Hi all,

if I understood well the rdapConformance content in the help response should be different from that included in the other responses. Right?

I misunderstood Scott's proposal as a mean by which a server could inform a client about the supported features any time regardless the response content.

In that sense, I proposed the server could distinguish the rdapConformance content according the user profile.


I have no objection to this solution but I think that the two cases above should be outlined in RFC7483bis.

Best,

Mario

Il 31/07/2020 18:50, Jasdip Singh ha scritto:
Agree with Patrick's points about rdapConformance in the help response 
informing about all capabilities and rdapConformance being more specific for a 
particular query response.

Jasdip

On 7/31/20, 12:29 PM, "regext on behalf of Patrick Mevzek" 
<regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote:

     On Fri, Jul 31, 2020, at 11:21, Hollenbeck, Scott wrote:
     > Note "supported extensions". This is why I'm saying that we need to
     > register all extensions with IANA
I agree. > and include them in the
     > rdapConformance data structure even if they don't describe a response
     > extension.
I agree, everything should be listed in the reply to an help query. I am just saying that for any other reply that is a specific one on a specific resource
     then the rdapConformance should just list the "extensions" needed to 
understand this
     specific response, and not list absolutely all extensions the server knows 
about
     (and that are irrelevant for this specific response).
The list of what is written in the response should certainly not be just server policy,
     especially if there is no automated way to learn about this policy. 
Otherwise if you include
     options like that (the list presented might be the list of all server 
extensions OR only the subset needed for this specific response) AND there is 
no way for the client to know which
     case he is in, it immediately creates interoperability problems. I prefer 
no such options
     and the protocol clearly defining the content. Or if such options are 
really needed
     (if help response is always all extensions, and any other response is just 
the specific extensions needed, then nothing more is needed), there should be  
a signal to know which
     case we are in.
> The help response should include supported
     > extensions that are available to that client.
Yes, the help response allows to "discover" all possible extensions from a specific client. --
       Patrick Mevzek
       p...@dotandco.com
_______________________________________________
     regext mailing list
     regext@ietf.org
     https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

--
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Reply via email to