Yes, please re-post to the netconf ML. Also, though not your primary point, you misquoted the example. The 2nd example in Section 3.1 returns “/top/restconf” (not “/restconf”), which is consistent with it subsequent use-example quoted below.
Kent On 6/13/16, 2:34 AM, "netmod on behalf of Juergen Schoenwaelder" <netmod-boun...@ietf.org on behalf of j.schoenwael...@jacobs-university.de> wrote: >Hi, > >this comment seems to be long to NETCONF and not NETMOD. > >/js > >On Sun, Jun 12, 2016 at 10:14:17PM -0400, Dale R. Worley wrote: >> Looking at draft-ietf-netconf-restconf-13, it looks like the RFC 7320 >> mechanism is used to find the root URL, from which all the Restconf URLs >> are derived by appending path components as specified in the draft. >> >> But looking at RFC 6570, which is referenced by both 7320 and the draft, >> it seems like appending path components to a configured base URL is no >> longer best practice, because it requires the HTTP server to be able to >> connect all those URLs to the Restconf server despite their different >> paths. It seems like the new, improved method is for a URL template to >> be advertised, and the Restconf client should use the template and the >> Restconf specification to construct the URL to be used. >> >> E.g., now, the example in section 3.1 shows how the Restconf root is >> obtained: >> >> Request >> ------- >> GET /.well-known/host-meta HTTP/1.1 >> Host: example.com >> Accept: application/xrd+xml >> >> Response >> -------- >> HTTP/1.1 200 OK >> Content-Type: application/xrd+xml >> Content-Length: nnn >> >> <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'> >> <Link rel='restconf' href='/restconf'/> >> </XRD> >> >> and used, with the sub-URL "operations": >> >> Request >> ------- >> GET /top/restconf/operations HTTP/1.1 >> Host: example.com >> Accept: application/yang.api+json >> >> RFC 6570 seems to suggest that the first lookup should return a URL >> template: >> >> Request >> ------- >> GET /.well-known/host-meta HTTP/1.1 >> Host: example.com >> Accept: application/xrd+xml >> >> Response >> -------- >> HTTP/1.1 200 OK >> Content-Type: application/xrd+xml >> Content-Length: nnn >> >> <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'> >> <Link rel='restconf' href='http://example.com/{resource}'/> >> </XRD> >> >> The value of this being that a different server might return the >> template 'http://example.com{?resource}', causing the second request to >> use the URL 'http://example.com?resource=operations'. >> >> Although this probably requires a redefinition of the href attribute of >> the Link element. >> >> Dale >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
