3.1.5.2 Method Formatting

A set of formatting conventions are used for each FrontPage Server Extensions method specified in the Methods section (section 3.1.5.3) later in this document.

The Methods section begins with a brief description of the method's purpose. The Tokens section follows the description and corresponds to the REQUEST element that specifies the set of arguments for each method. Clients can pass in any subset of the given arguments, although some arguments are required. If an argument is not required, unless otherwise specified, the server SHOULD use a default value of FALSE for BOOLEAN arguments, 0 for INT, UNSIGNED-INT, and DOUBLE arguments, an empty string for STRING and URL-STRING arguments, an empty METADICT for METADICT arguments, and an empty VECTOR-X 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.<29>

Each argument definition starts with an argument name in bold type. 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 URL 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 Fields section. The RET-NAME corresponds to the return value name in bold type. The format of the RET-VALUE is defined by the return value type. Servers can return arguments in any order, and clients MUST accept the parameters in any order.

In error conditions at the FrontPage Server Extensions Remote 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 (see 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 Remote 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 Remote Protocol server, the server SHOULD respond with an HTTP 401 as specified in [RFC2616] section 10.4.2. It MAY include an entity body containing a descriptive error message in the response.<30>