Vince, This is a good start, however I think it may worth adding some more context to it. For instance, that some regulators certify a limited number of databases for operation in WS; that some regulators plan to maintain a website listing all approved databases, others may not.
The document also needs to address how to keep the preconfigured list of databases up-to-date. Eg, when a preconfigured certified DB, which the master used to contact, is going to shut down/go out of business/close down. In case a listing web site exists, should the master every now and then check if its preconfigured list of DBs matches with the list on the web site, and update accordingly. Master error handling: if one of the DB on in its preconfigured list is contacted, and there is no response, or there is an error response (eg 102 unsupported), what should the master do next. What if none of the preconfigured DBs work. The behavior to some of the points above may be obvious, but I think it still needs to be spelled out. - gabor From: [email protected] [mailto:[email protected]] On Behalf Of ext Vincent Chen Sent: Wednesday, March 27, 2013 10:10 AM To: [email protected] Subject: [paws] Database Discovery: static provisioning All, At the F2F, it was decided to update the language in the draft-ietf-paws-protocol to explicitly allow static provisioning, while leaving room to adopt dynamic provisioning, when it's defined. Here is the proposed language. Comments are welcomed. Thanks -vince ------------------------------ 4.1. Database Discovery The Device MUST determine the URI for the Database before it can send PAWS messages. The Device MAY be provisioned statically with the URI of one or more Databases. The Device SHOULD be provisioned with the URI of all the databases for which it is certified or otherwise permitted to operate. The Database MAY redirect a PAWS request by returning a HTTP 3xx response, as defined by HTTP/1.1 [RFC2616]. The Database MUST provide the redirect URI in the Location header of the 3xx response, and the Device MUST handle redirects by using the Location header provided by the Database. When redirecting, the Device MUST observe the delay indicated by the Retry-After header. The Device MUST authenticate the Database that returns the redirect response before following the redirect. Additionally, the Device MUST authenticate the Database indicated in the redirect. Because the Device may communicate with the Database without user interaction and because the Device authenticates the Database, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation, which is an exception to the HTTP/1.1 [RFC2616] requirements for HTTP POST methods. The Device MAY obtain the URI of one or more Databases dynamically from authorized and authenticated entities. The Device SHOULD use dynamic provisioning of Database URI when the mechanism is defined.
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
