this week's changes are at:
https://github.com/anima-wg/brski-cloud/pull/248/filesThe previous PR got merged too soon. Mike Bishop <[email protected]> wrote: > Okay. Didn't know about that document. > Is this what you had in mind: > https://github.com/anima-wg/brski-cloud/pull/247/commits/3e721e8ce55226a3a97cfadfba04d0670a62b11f > [MB] I don't know that you need a section reference every time you > mention a status code, though you certainly can. I was thinking more of > the places you say "as defined by [BRSKI] and HTTP" but HTTP isn't a > reference to 9110. Turning that into [HTTP] would make sense. I've done exactly this now. > I don't know what you mean here. > I think that "Link relation" involves RDF or HTML stuff, and we are not using either. > [MB] Link relations are defined in RFC8288, and allow an HTTP header to > describe the relationship of other resources to the one being > accessed. However, if the redirect payload is the same, redirects will > work. I read through 8288. I see that we can use this Link: header, and rather than the meta http-equiv way that I'm more familiar with. I looked through https://www.iana.org/assignments/link-relations/link-relations.xhtml Nothing jumped out as an existing link type that we could use, that would be somehow more useful than 307. > Any other 3xx that redirected to a different origin would have to be rejected outright. > 303 with Location: header seems similar to 201+Location: header, which we > explicitely allow in the Registrar<->MASA interaction in RFC8995. > I can add text explaining why the rest of 3xx are all probably wrong, but I'm > not sure about 303 yet. MB> Yes, it's similar, and a 201 is probably even more appropriate given MB> that the response will need to be unique to the request rather than MB> being an existing resource that satisfies the client's request. The MB> more general point is that just after the section of RFC 9205 you cite below, it says: I'm used to 201+Location to refer to a *unique* place that should be polled (GET,HEAD,If-*) to get the result. But, at each step, Cloud Register X does not know what the unique URL for Cloud Register X+1 would be. 307 seems the correct answer to me. Go *THERE* and do a POST. > -The details of the URI are Manufacturer specific, with BRSKI giving the example "brski-registrar.manufacturer.example.com". > - > -The Pledge SHOULD be provided with the entire URI of the Cloud Registrar, including the protocol and path components, which are typically "https://"; and "/.well-known/brski", respectively. > +The details of the URI are Manufacturer specific. > +For example, https://brski-registrar.manufacturer.example.com/.well-known/brski. MB> Okay, I see the definition in 8995. It's fine to parallel that MB> construction here — copying the language about assuming the scheme and MB> path components if they're omitted, for example. But saying it's MB> manufacturer-specific and leaving them to deal with it works, too. In 8995, we allow the IDevID extension to be just the `authority` to be save a dozen bytes. But maybe in ten years, https will be all cringe. The Registrar has to know this, so it's not a private matter. But, in the Cloud-Registrar process, the manufacturer controls the first step (Pledge->First Registrar), and then it's all supply-chain specific, and fully specified by the 307 chain. > I think that we've tried to do this, and I think that we haven't tried to > jump on wrong codes, nor make a one-to-one relationship. We have identified > some errors that map to specific codes (so many-to-one). > [PROBLEM-DETAILS] could be useful, but who would the pledge tell given that > it has no UI or user. Not telling people not to use it. MB> Ah, so it's a matter of the requested identity/manufacturer not being MB> found on the server. That mapping makes sense with context, thanks. Exactly. > { > Note that we avoided 418. We really wanted to :-) > Well, technically it would have been: "You are teapot" > } MB> Maybe the pledge could use it from its management interface. One MB> of the few areas of the IETF that could realistically specify a use for MB> 418! NO SIR! I can also Brew expresso-sized Cappacinos! (as the machines in Madrid seemed to be...) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
