Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-partial-response

[Patrick Mevzek <[e-mail]>]

On Mon, Apr 27, 2020, at 11:46, Mario Loffredo wrote:
> Il 27/04/2020 08:04, Patrick Mevzek ha scritto:
> > Also:
> > couldn't each fieldset have a list of jsonPath elements (similar to what is done in
> > draft-ietf-regext-rdap-sorting-and-paging)
> > to properly list the fields concerned?
> I dropped this solution because it seemed to me conceptually valid but 
> very inefficient.

Ok, I see.

> > TBH, I am not sure to understand:
> > - why there are multiple links elements (the example given shows only one, what would be other ones?)
> The figure is uncorrect. I missed to fix this issue in the last version. 
> There are multiple field sets but each field set includes a single link 
> because each field set is an alternative view of the results provided 
> according to the current field set.

Great, that was my understanding too.

> > - why value there is different from href (and hence why value is needed at all),
> > why is the current fieldSet the "context URI" of any other fieldset used for same query?
> >
> > RFC8288 defines the context URI to be, for HTML serialization:
> > "The context of the
> >     link is the URI associated with the entire HTML document. "
> 
> The use of both the "value" and the "href" JSON values is compliant to 
> what is shown in RFC7483. The context is the URI of the current view of 
> a resource (i.e. the collection of objects returned according to the 
> current fiel set) while the target is the URI of an alternative view of 
> the same resource (i.e. the collection of objects provided according 
> another field set).

Ok. Maybe put that in the draft (value = current document, href = other document with other fieldset applied)>
 
> > There is no real explanation of the context for RDAP, but based on that maybe
> > it should be a link to the same query with fieldSet "full"?
> 
> I think that we need to agree about the meaning of "context" in RDAP. It 

Yes, I need this point should be explained better in rfc7483bis,
hoping that it could be considered as a clarification/correction point.

-- 
  Patrick Mevzek
  [e-mail]