Looks good, thanks. > On 11 Feb 2021, at 9:44 am, Phil Sorber <sorber@xxxxxxxxxx> wrote: > > Here is the PR for this review: https://github.com/PSUdaemon/URISigningSpec/pull/67 > > On Tue, Feb 9, 2021 at 8:05 PM Mark Nottingham <mnot@xxxxxxxx> wrote: > Hi Phil, > > I think that makes sense -- thanks. Happy to review text when you get to it. > > Cheers, > > > > On 10 Feb 2021, at 1:25 pm, Phil Sorber <sorber@xxxxxxxxxx> wrote: > > > > Mark, > > > > I took some time to read through BCP190 and spoke with some experienced people offline to make sure I was as informed as possible. I also read through RFC 6570 (URI Template) which seemed promising but has a fatal flaw for my use case. My document relies on another WG document (RFC 8006) to handle disseminating configuration data between the Content Service Providers and the various levels of CDNs. The intent is that processing of this data is done in an automated manner. So a requirement for my document is that however I configure where the URI Signing Package is in the URI, it needs to be able to be processed programmatically. Using URI Templates I can take a template and variables and create a URI, but I cannot take a template and a URI and derive the variables. The syntax makes it ambiguous. > > > > Additionally, the text you cited is my clumsy attempt to describe how to parse URI query parameters, and not how to generate a URI. Our parameter key is also not specified in the document, but passed out of band. All that is required in the document is for the recipient to be able to parse path parameters and query parameters looking for the previously agreed upon key name. > > > > Furthermore, upon reading of RFC 6570 I see references to "path-style parameters" and "form-style parameters" with no normative or informative reference accompanying it. That would lead me to believe that my text on how to parse these isn't needed and is only likely to cause confusion to implementers. > > > > So what I would like to propose as a change is that I remove my parameter parsing text and replace it with text stating something to the effect of "MUST parse all path-style and form-style parameters and SHOULD use the first instance a key with the previously agreed upon name." I believe this is still in the spirit of BCP 190. > > > > Thanks. > > > > On Fri, Feb 5, 2021 at 8:18 PM Mark Nottingham <mnot@xxxxxxxx> wrote: > > I have trouble getting through this quite dense document. However, this text: > > > > ~~~ > > The URI Signing Package will be found by searching the URI Query string [RFC3986] (see [RFC3986] Section 3.4), left-to-right, for the following sequence: > > o the URI Signing Package Attribute name, > > o an equal symbol ('='), > > o and a sequence of zero or more non-reserved characters (as defined in [RFC3986] Section 2.3) that will be interpreted as a signed JWT, > > o terminated by either any reserved character (as defined in [RFC3986] Section 2.2) or the end of the URI Query string. > > ~~~ > > > > leads me to believe that it doesn't line up with BCP190. > > > > Cheers, > > > > > > > On 6 Feb 2021, at 10:12 am, The IESG <iesg-secretary@xxxxxxxx> wrote: > > > > > > > > > The IESG has received a request from the Content Delivery Networks > > > Interconnection WG (cdni) to consider the following document: - 'URI Signing > > > for Content Delivery Network Interconnection (CDNI)' > > > <draft-ietf-cdni-uri-signing-20.txt> as Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and solicits final > > > comments on this action. Please send substantive comments to the > > > last-call@xxxxxxxx mailing lists by 2021-02-19. Exceptionally, comments may > > > be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning > > > of the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > This document describes how the concept of URI Signing supports the > > > content access control requirements of Content Delivery Network > > > Interconnection (CDNI) and proposes a URI Signing method as a JSON > > > Web Token (JWT) profile. > > > > > > The proposed URI Signing method specifies the information needed to > > > be included in the URI to transmit the signed JWT, as well as the > > > claims needed by the signed JWT to authorize a User Agent (UA). The > > > mechanism described can be used both in CDNI and single Content > > > Delivery Network (CDN) scenarios. > > > > > > > > > > > > > > > The file can be obtained via > > > https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/ > > > > > > > > > The following IPR Declarations may be related to this I-D: > > > > > > https://datatracker.ietf.org/ipr/2603/ > > > https://datatracker.ietf.org/ipr/4628/ > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > IETF-Announce mailing list > > > IETF-Announce@xxxxxxxx > > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > -- > > last-call mailing list > > last-call@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/last-call > > -- > > last-call mailing list > > last-call@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/last-call > > -- > Mark Nottingham https://www.mnot.net/ > -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
