[httpapi] Orie Steele's No Objection on draft-ietf-httpapi-api-catalog-06: (with COMMENT)

[Orie Steele via Datatracker <[e-mail]>]

Orie Steele has entered the following ballot position for
draft-ietf-httpapi-api-catalog-06: No Objection

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 https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpapi-api-catalog/



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

# Orie Steele, ART AD, comments for draft-ietf-httpapi-api-catalog-06
CC @OR13

* line numbers:
  -
  https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-httpapi-api-catalog-06.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Almost a Discuss

There is an open expert review comment for -06 and IANA is listed as not OK.

I read the expert's comment and I think I agree with them.

>From https://datatracker.ietf.org/doc/html/rfc8288#section-2.1.1.1

```
o  *Description*: A short English description of the type's
      semantics.  It SHOULD be stated in terms of the relationship
      between the link context and link target.
```

I believe that context was used correctly in -05, and ... I can see from the
list there are plans in the works to correct this:

https://mailarchive.ietf.org/arch/msg/httpapi/w8VtmpTdXLah8lfyGKkOzptOOLo/

## Comments

Thanks to Tim Bray for the ARTART Review, and the the authors for addressing
his comments.

As a general comment there appear to be a lot of BCP14 SHOULD's that are really
"you ought to", and that do not have an impact on interoperability or security,
I've opted not to ask the question "when can this SHOULD be ignored" on each of
them.

### Why is HEAD not mandatory?

```
186        *  SHOULD resolve an HTTPS HEAD request to /.well-known/api-catalog
187           with a response including a Link header with the relation(s)
188           defined in Section 3
```

When can this SHOULD be ignored?

### Which URL?

```
259        *  A linkset in JSON Document format (section 4.2 of [RFC9264]) of
260           API endpoints and information to facilitate API usage.  The
261           linkset SHOULD include a profile parameter (section 5 of
262           [RFC9264]) with a Profile URI [RFC7284] value of 'THIS-RFC-URL' to
263           indicate the linkset is representing an API Catalog document as
264           defined above.  Appendix A includes example API Catalog documents
265           based on the linkset format.
```

```
550        RFC Editor's Note: IANA is kindly requested to replace all instances
551        of THIS-RFC and THIS-RFC-URL with the actual RFC number/URL once
552        assigned.
```

Maybe its obvious but I assume this is not a link to the datatracker?

### Informative section with BCP14 RECOMMENDED?

```
662        This section is informative and provides and example of an API
663        Catalog document using the RECOMMENDED linkset format.
```

Also isn't linkset mandatory to support?