Gabor, Acknowledged. I'll take another stab at the additional points on how to maintain the lists.
On Mon, Apr 1, 2013 at 10:05 AM, <[email protected]> wrote: > 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.**** > > ** ** > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
