3.1.5.2 Method Formatting

A set of formatting conventions is used for each FrontPage Server Extensions method, as specified in section 3.1.5.3.

Each method begins with a brief description of the method's purpose. A Parameters section follows the description and corresponds to the REQUEST (section 2.2.2.2.7) element that specifies the set of arguments for each method. Clients MAY pass in any subset of the given arguments, although in some cases specific arguments are required. If an argument is not required and unless otherwise specified, the server SHOULD use a default value of FALSE for BOOLEAN (section 2.2.2.1.3) arguments, 0 for INT (section 2.2.2.1.2), UNSIGNED-INT (section 2.2.2.1.1), and DOUBLE (section 2.2.2.1.4) arguments, an empty string for STRING (section 2.2.2.1.5) and URL-STRING (section 2.2.2.2.3) arguments, an empty METADICT (section 2.2.2.2.11) for METADICT arguments, and an empty VECTOR-X (section 2.2.2.2.1) for VECTOR-X type arguments. Clients MAY pass the arguments in any order, and servers MUST accept them in any order. Clients SHOULD NOT pass arguments unless they are mentioned in this document. When a server is passed an argument that it does not recognize, the server SHOULD treat it as a syntax error. It MAY choose to ignore the parameter instead.<20>

Each argument definition starts with an argument name in italics. The argument name corresponds to the ARG-NAME element. The data type is listed in the argument description, and it defines the required format for the ARG-VALUE element.

The Entry Point section defines the URL as provided by _vti_inf.html, to which clients MUST post when using this method.

The Return Values section specifies the set of return values, and its formatting is similar to the Parameters section. The RET-NAME (section 2.2.2.2.8) corresponds to the return value name in bold. The format of the RET-VALUE is defined by the return value type. Servers MAY return arguments in any order, and clients MUST accept the parameters in any order.

In error conditions at the FrontPage Server Extensions: Website Management Protocol level, the server SHOULD return a RET-NAME RET-VALUE pair where the RET-NAME is "status" and the RET-VALUE is a STATUS object (as specified in section 2.2.2.2.17). A client SHOULD ignore all other return values if a status is present. Even though this is an error, it SHOULD be encapsulated in an HTTP 200 response, as specified in [RFC2616] section 10.4.2.

Lower layers (such as HTTP or IP) can also return errors. For example, the FrontPage Server Extensions: Website Management Protocol layer on the server SHOULD indicate to the HTTP layer that it requires authentication, which in turn SHOULD cause the HTTP layer to send a 401 message in response (as specified in [RFC2616] section 10.4.2) to unauthenticated requests.

If the lower layers pass on an unauthenticated request from the client to the FrontPage Server Extensions: Website Management Protocol server, it SHOULD respond with an HTTP 401, as specified in [RFC2616] section 10.4.2. It MAY include an entity body that contains a descriptive error message in the response.<21>