- From: Judith Slein <slein@wrc.xerox.com>
- Date: Wed, 27 Aug 1997 14:27:52 PDT
- To: w3c-dist-auth@w3.org
What if we tried just to do something along these lines (details of syntax aren't important to me) -- Would this be too painful for server vendors to consider? Would it meet the needs of those of us who build applications? (The section numbers look weird because I took this from a longer paper I've been working on.) --Judy --------------- 3 General Principles 3.1 Do not dictate any algorithm for choice of rendition 3.2 Do not assume anything about the naming scheme the server uses for renditions, or even that it uses a naming scheme to track rendition relationships 3.3 Support both persistent and dynamically generated renditions in a consistent way 4 Requirements and Solutions 4.1 Clients must be able to find out what renditions of a resource are available HTTP 1.1 discusses only in vague terms (in 12.2 and 19.6.2.1) how a server would describe what variants it has available. It reserves the header name "Alternates" for this purpose, but does not define that header. The Transparent Content Negotiation (TCN) draft Draft-ietf-http-negotiation-03.txt proposes a definition (in 10.1). This section treads on some ground being addressed by the TCN draft, but gives us a way of getting a rendition list without tampering with the semantics of HTTP 1.1 GET. Request: RENDITIONLIST /~slein/Book/ HTTP/1.1 Host: www.xerox.com Response: HTTP/1.1 200 OK Alternates: {"http://www.xerox.com/~slein/Book/french.html" 0.9 {type text/html} {language fr}}, {"http://www.xerox.com/~slein/Book/english.html" 1.0 {type text/html} {language en}} 4.2 Clients must be able to submit renditions of a resource to a server Make a RENDITION request, with the request URI being the URL of the parent resource, and with headers describing the renditions. A suggested URL for the rendition may be included, but the server is not required to use it. The response must include the URLs where the server actually put the renditions. If the parent resource does not exist, the server should create it. Quality here is the user agent's estimate of the quality of the rendition being provided. If a rendition matching a variant description (URL and quality are not used in determining a match?) already exists, it will be replaced. Request: RENDITION /~slein/Book/ HTTP/1.1 Host: www.xerox.com Content-type: multipart/alternate Alternates: {"./french.html/" 0.9 {type text/html} {language fr}}, {"./english.html/" 1.0 {type text/html} {language en}} <entity body> Response: HTTP/1.1 200 OK Content-type: application/xml <XML> <XML:Namespace><Ref>http://www.ietf.org/standards/dav/</>As>D</></> <D:MultiResponse> <Response> <XML:Ref>http://www.xerox.com/~slein/Book/</> <Status>HTTP/1.1 200 OK</> </> <Response> <XML:Ref>http://www.xerox.com/~slein/Book/french.html/</> <Status>HTTP/1.1 200 OK</> </> <Response> <XML:Ref>http://www.xerox.com/~slein/Book/english.html/</> <Status>HTTP/1.1 200 OK</> </> </> </> 4.3 Clients must be able to get a particular rendition of a resource HTTP takes care of this, up to a point. For renditions that are resources, a client can simply GET the resource. For renditions that are not resources, content negotiation can be used - the client specifies which renditions it can accept. What is not defined is a way for the client to discover what renditions are available. See 4.1 for the proposed solution to this part of the problem. 4.4 Dynamic generation of renditions One rendition may be designated "master", or a "generated from" link may be defined, or both. The master rendition is the one from which all others get generated. In some environments this may be a server-maintained property. If there is a master rendition, it is the only one users are allowed to edit, and other renditions are generated as needed based on changes to the master. Values "true", "false". This property should only be present on renditions that are source or output for dynamic generation. The generated from link . . . The GENRENDITION method provides a way to request generation of derived renditions. (In many cases generation of renditions may happen automatically, without the need for a request. But there will be occasions when a request is needed - say, automatic generation happens at 2:00 AM, but the author needs to make new generations available immediately.) The request URL is the URL of the parent resource. If no list of alternates is provided, all renditions will be regenerated from the master resource. If a list is provided, only the renditions on the list will be regenerated. 4.5 Interoperability with HTTP content negotiation Provide enough information in a RENDITION request to support HTTP 1.1 content negotiation - at least media type, language, charset, and encoding. What about Transparent Content Negotiation? Let's not add anything else (no features). Name: Judith A. Slein E-Mail: slein@wrc.xerox.com Internal Phone: 8*222-5169 External Phone: (716) 422-5169 Fax: (716) 265-7133 MailStop: 105-50C
Received on Wednesday, 27 August 1997 17:24:28 UTC