Max, In section 5.5 we outline a number of HTTP codes that can be returned From the MASA and from the Registrar.
In my coding I did a few dumb things (like testing against the wrong code base) which resulted in my MASA failing and return error code 500 to the Registrar. What should the Registrar do? It seems that we ought to say more about how MASA error codes translate into codes being returned to the Pledge is a more coherent fashion. I was thinking that maybe all 4xx codes returned from the MASA result in a specific 4xx (not necessarily the same one) code being returned to the Pledge. I am less certain that a 5xx code from the MASA ought to result in a specific 5xx code to the pledge. For instance, there are a number of network conditions that might occur between the Registrar and MASA which, to the Pledge probably mean: just hang on and try again. Or might even result in a 201 code being returned and the Pledge could/should poll that location for an update. I partly think that this might be simply be future work (in which case, we should say this): for that step from DS to IS, where we have actual experience to be able to map things. Or perhaps we would start a document collecting experiences. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
