Re: [core] Late review of draft-ietf-core-target-attr-02

[Carsten Bormann <[e-mail]>]

Hi Christian,

> On 2023-03-01, at 15:07, Christian Amsüss <[e-mail]> wrote:
> 
> Signed PGP part
> Hi all,
> 
> sorry for being late to the party, here's a few notes:

Thank you.

> * Should this contain all attributes used in published RFCs with 6690?

Yes.

>  If so, there's some in RFC9176 Resouce Directory, and the RD
>  Parameters Registry should be updated with a note that all "A"-used
>  entries should also get registered over here.

Makes sense.

> * Some documents introduce target attributes for specific resource types
>  or rels; example [1].
> 
>  Should we account for that?
> 
>  If so, the `base`, `et` `d` and `ep` of RFC9176 Resource Directory
>  would be limited to rt=core.rd-ep.

Well, the names are pretty much gone.
They might obtain slightly different semantics in a different context.
So there might be multiple stakeholders for a single name.

> * Why is href reserved? Is there anyone else apart from the abandoned
>  links-json who uses it that way?

We decided not to standardize links-json as an interchange format, instead deferring to CoRAL (which is still a check without cover… so I’m not even sure I would recommend against using links-json as an interchange format).
However, links-json is still the preferred way to carry link-format information around within an implementation.

But we didn’t invent href, compare Appendix A of RFC 8288.

Most importantly, 6690 says:

   parameters.  The link parameter "href" is reserved for use as a query
   parameter for filtering in this specification (see Section 4.1) and
   MUST NOT be defined as a link parameter.  As in [RFC5988], multiple


>  (To be clear: I'm in favor of having it there, if only b/c an internal
>  representation of a link can then use it there, but it might warrant a
>  footnote).

Indeed.

> Other than that: Thanks, good document, let's go. (And I may want to
> hook into the registry with CoRAL).

Definitely!

Grüße, Carsten