|
Hi Tim, thanks for the review. Here are our comments: >> RFC8288 is careful to decouple link types and media types, but the lack of a media type does feel like a gap. The ASAP draft does define a new media type, but after a chat with the authors this media type will be changed to “application/json” to both keep things simple and avoid the need to register a new media type. This change will be added in
a subsequent version of the implementation draft. >> - In the GET example in section 3, maybe a note that the line-breaks & indentation are there for clarity?
Agreed, we can add a comment that the following example includes additional line-breaks and indentation for clarity. >> - In the security considerations, perhaps a reference to draft-ietf-asap-sip-auto-peer#name-security-considerations would be helpful? Sure, we can add some text along the lines of “Security considerations specific to the capability set document are documented here” and provide a link to the ASAP draft. Thanks again for the support and the review. Derek -- Derek Engi deengi@xxxxxxxxx
From: Asap <asap-bounces@xxxxxxxx> on behalf of Tim Bray <tbray@xxxxxxxxxxxxxx> [Now with line breaks. Sorry.] - Reading section 1, I wondered what dereferencing a URI with this link type would yield. Following the reference to draft-ietf-asap-sip-auto-peer-07, I eventually found
the YANG definition, but I was a little surprised that it didn't seem to register a media type? Now, RFC8288 is careful to decouple link types and media types, but the lack of a media type does feel like a gap. - In the GET example in section 3, maybe a note that the line-breaks & indentation are there for clarity? As presented it's not a valid GET request. - In the security considerations, perhaps a reference to draft-ietf-asap-sip-auto-peer#name-security-considerations would be helpful? On Fri, Mar 10, 2023 at 9:43 AM Tim Bray via Datatracker <noreply@xxxxxxxx> wrote:
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
