K. Holtman and A. Mutz, "Transparent Content Negotiation in HTTP" IETF RFC 2295, 1998.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....and negotiation aspects in the protocols. The HTTP [12] protocol is an example of a communication protocol. The negotiation protocol carry information related to the content negotiation and adaptation. One possible approach is to integrate the two in a single protocol. The HTTP 1.0 and HTTP 1. 1 [8] represent an example of such protocols. Using HTTP 1.0, the client context is sent inside the user agent request through a set of accept headers. The content negotiation is applied at the server side and consists in applying content variant selection. The client description in HTTP 1.1 is ....

....the user agent request through a set of accept headers. The content negotiation is applied at the server side and consists in applying content variant selection. The client description in HTTP 1.1 is achieved in a similar way. However, the server applies transparent content negotiation strategy [8] by sending the list of available variants and their properties to the client. Here, the responsibility of selecting the best variant is left to the user agent. Another exchange protocol is presented in [7] The protocol, called CC PP exchange protocol, defines a way for exchanging clients ....

[Article contains additional citation context not shown here]

Holtman K., TUE and Mutz A. Transparent Content Negotiation in HTTP. RFC 2295, Network Working Group, March 1998.

....data transfer or loss in negotiation (HTTP 1.1) quality; extra server storage (server driven) Content Yes Yes Yes Wasteful data transfer or loss in negotiation (HTTP 1. 1) quality; extra server storage; extra (agent driven) network round trip for the initial server format advertisement [17] Web ad blockers Yes No No Customized name resolution file and loss of some objects Pipelining Yes Yes No Need trusted proxy to assemble the (1 chunk) entire page on behalf of the client Pipelining Yes Yes No None (2 chunk ( TTP 1.1 ( TP 1.1 Multiple browsers No No No Hard to ....

K. Holtman and A. Mutz. Transparent Content Negotiation in HTTP. Internet RFC 2295, March 1998.

....objects. The sender uses the cm query( call and the change rate( handler to adapt to changing available bandwidths (tracked by the CM) and pick the representation that maximizes receiver quality without incurring high latency. We are currently extending the HTTP content negotiation protocol [15] to incorporate these ideas. It really does not matter what version of HTTP, but as we will see in Section 5, the use of persistent connections in P HTTP has some drawbacks. 15 Data Structures: struct cm entry addr dst; double rate; double mean rtt; double rttvar; typedef int ....

HOLTMAN,K. Transparent Content Negotiation in HTTP. RFC, March 1998. RFC-2295.

....already followed, and other useful information that may help to adapt the workflow traversal and the course content. Based on those profiles, the negotiation task can be applied dynamically and added to the currently followed set of courses. Since actual protocols, such as HTTP [14] and TCN [6], are based on pure versioning selection mechanisms and lack negotiation support, a perspective for these negotiation services is to use a negotiation layer on top of these protocols [12] The use of a specific intermediate entity for negotiation purposes between the student and the execution ....

Holtman, K., Mutz, A.: Transparent Content Negotiation in HTTP. RFC 2295. Network Working Group. (

....in this area have already been well investigated within the adaptive hypertext literature [5] A possible method to automate this on the Web is the use of HTTP cookies [17] ffl Content negotiated links. The Hypertext Transfer Protocol (HTTP) 13] supports a mechanism called content negotiation [15], which enables clients to communicate their preferences (content types, content languages, and other content properties) to a server, which responds with a response best suited for the client s preferences. Link based information providers can dynamically create link sets which are based on the ....

K. Holtman and A. H. Mutz. Transparent Content Negotiation in HTTP. Internet experimental RFC 2295, Mar. 1998.

....user preferences and application interactions enables application level decisions about the most appropriate way to adapt to a situation. We believe that it is need for a more flexible solution than just the provision of standard translations or restrictions according to device parameters, as in [6,7,8,9]. These may be part of the solution, particularly for very small devices. However, when using devices of the next level of capability (PDA to laptop, kiosks, in car systems, etc. the device itself ceases to be an absolute limitation. The user interface and network connection are often both ....

..... A weighting is defined for a specific encoding format (e.g. GIF = 0.9, JPEG = 0.8) or text language (e.g. French = 0.8, English = 0.5) to indicate the user s preference or capability of the user s device. These weights are generally used in a selection mechanism provided with the data request [7,8,9]. A standard transcoding may be applied to data in order to provide it in a particular format, or to meet device restrictions. Commonly image size and colour depth are adjusted to meet the needs of restricted client devices. These transcoders are generally implemented as in network proxies ....

[Article contains additional citation context not shown here]

K. Holtman and A. Mutz, "Transparent Content Negotiation in HTTP," IETF RFC 2295, 1998.

....user preferences and application interactions enables application level decisions about the most appropriate way to adapt to a situation. We believe that it is need for a more flexible solution than just the provision of standard translations or restrictions according to device parameters, as in [6,7,8,9]. These may be part of the solution, particularly for very small devices. However, when using devices of the next level of capability (PDA to laptop, kiosks, in car systems, etc. the device itself ceases to be an absolute limitation. The user interface and network connection are often both ....

..... A weighting is defined for a specific encoding format (e.g. GIF = 0.9, JPEG = 0.8) or text language (e.g. French = 0.8, English = 0.5) to indicate the user s preference or capability of the user s device. These weights are generally used in a selection mechanism provided with the data request [7,8,9]. A standard transcoding may be applied to data in order to provide it in a particular format, or to meet device restrictions. Commonly image size and colour depth are adjusted to meet the needs of restricted client devices. These transcoders are generally implemented as in network proxies ....

[Article contains additional citation context not shown here]

K. Holtman and A. Mutz, "Transparent Content Negotiation in HTTP," IETF RFC 2295, 1998.

....such a case, the sender uses the cm query( call and the change rate( handler to adapt to changing available bandwidths (tracked by the CM) and picks the representation that maximizes receiver quality without incurring high latency. We are currently extending the HTTP content negotiation protocol [11] to incorporate these ideas. The Web server uses TCP to disseminate data, which in turn uses the CM to perform congestion management; thus, TCP over CM (denoted TCP CM) now performs only loss recovery and connection management. We now outline how TCP congestion control can be written as a CM ....

K. Holtman. Transparent Content Negotiation in HTTP. RFC, March 1998. RFC-2295.

.... a href= http: www.cs.columbia.edu doe John Doe a at li a href= sip: hgs erlang.cs.columbia.edu Internet telephony a li a href= phone: 1219397042 analog phone a li . 13.1 Variant Description A variant can be described in a machine readable way with a variant description [7]. variant description = UCI communication quality variant attribute communications quality = qvalue variant attribute = mobility ( fixed mobile ) class ( personal business ) language 1#language tag service 1#service tag ....

K. Holtman and A. Muntz, "Transparent Content Negotiation in HTTP," Internet Draft, Internet Engineering Task Force, Nov. 1997. Work in progress.

....objects. The sender uses the cm query( call and the cmapp update( handler to adapt to changing available bandwidths (tracked by the CM) and pick the representation that maximizes receiver quality without incurring high latency. We are currently extending the HTTP content negotiation protocol [14] to incorporate these ideas. The Web server uses TCP to disseminate data, which in turn uses the CM to perform congestion management; thus, TCP CM 2 now only performs loss recovery and connection management. We now outline how TCP congestion control can be written as a CM application. ....

Holtman, K. Transparent Content Negotiation in HTTP. RFC, March 1998. RFC-2295.

....has been taken in [12] However, their work does not consider the implications of providing multiresolution on other system components such as caching and deals solely with versions that can be generated automatically. There is considerable interest in the web community on content negotiation [14]. Unlike our approach where the user is presented with the list of options, the focus there is to augment the HTTP protocol so that the client and the server can automatically negotiate the best (materialized) version for the client. Web caching has been studied extensively in the lit9 erature ....

K. Holtman and A. Mutz. Transparent content negotiation in HTTP. WWW, URL: http://www.ietf.org/ids.by. wg/http.html, February 1998.

....the more appropriate choice. By using HTTP as a base, the protocols can immediately reuse a number of evolving protocols for electronic commerce [18] authentication [19] content labels and client side access control [20] protocol extensions [21] state management [22] and content negotiation [23]. Also, servers, proxies and firewalls, all already tuned for high performance, manageability and reliability, can be easily modified to accommodate these new protocols. The commonality between SIP and RTSP also simplifies implementations as many clients and servers can be expected to implement ....

K. Holtman and A. Muntz, "Transparent Content Negotiation in HTTP," Internet Draft, Internet Engineering Task Force, Nov. 1997. Work in progress.

....that one request header value is compatible with another, without being equal. The HTTP 1. 1 development effort included an attempt to provide so called transparent content negotiation that would allow caches some active participation, but ultimately no consensus developed, and this attempt [15, 16] was separated from the HTTP 1.1 specification. 4 Bandwidth optimization Network bandwidth is almost always limited. Both by intrinsically delaying the transmission of data, and through the added queueing delay caused by congestion, wasting bandwidth increases latency. HTTP 1.0 wastes bandwidth ....

....of each representation s properties (such as its language and character set) The client (agent) then chooses one representation, either automatically or with user intervention, and resubmits the request, specifying the chosen variant. Although the HTTP 1. 1 specification reserves the Alternates [15] header name for use in agentdriven negotiation, the HTTP working group never completed a specification of this header, and server driven negotiation remains the only usable form. Some users may speak multiple languages, but with varying degrees of fluency. Similarly, a Web resource might be ....

[Article contains additional citation context not shown here]

K. Holtman and A. H. Mutz, "Transparent Content Negotiation in HTTP," RFC 2295, HTTP Working Group, March 1998.

....the more appropriate choice. By using HTTP as a base, the protocols can immediately re use a number of evolving protocols for electronic commerce [23] authentication [24] content labels and client side access control [25] protocol extensions [26] state management [27] and content negotiation [28]. Also, servers, proxies and firewalls, all already tuned for high performance, manageability and reliability, can be easily modified to accommodate these new protocols. The commonality between SIP and RTSP also simplifies implementations as many clients and servers can be expected to implement ....

....used to introduce these protocols. 4. 1 Choosing Terminals and Locating Callees Many people have several ways of being reached, including a telephone, email, fax, or a pager, each with widely differing media handling capabilities [37] Borrowing the concept of HTTP transparent content negotiation [28], a SIP server can return a descriptive list of alternative terminals, their capabilities and addresses. In a local area, a person may move around from terminal to terminal, e.g. from lab to office to meeting room. Also, a call may be addressed to more than one individual (e.g. a whole ....

K. Holtman and A. Muntz, "Transparent Content Negotiation in HTTP," Internet Draft, Internet Engineering Task Force, Nov. 1997. Work in progress.

....that one request header value is compatible with another, without being equal. The HTTP 1. 1 development effort included an attempt to provide so called transparent content negotiation that would allow caches some active participation, but ultimately no consensus developed, and this attempt [HM98b, HM98a] was separated from the HTTP 1.1 specification. 4 Bandwidth optimization Network bandwidth is almost always limited. Both by intrinsically delaying the transmission of data, and through the added queueing delay caused by congestion, wasting bandwidth increases latency. HTTP 1.0 wastes ....

....of each representation s properties (such as its language and character set) The client (agent) then chooses one representation, either automatically or with user intervention, and resubmits the request, specifying the chosen variant. Although the HTTP 1. 1 specification reserves the Alternates [HM98b] header name for use in agentdriven negotiation, the HTTP working group never completed a specification of this header, and server driven negotiation remains the only usable form. Some users may speak multiple languages, but with varying degrees of fluency. Similarly, a Web resource might be ....

[Article contains additional citation context not shown here]

Koen Holtman and Andrew H. Mutz. Transparent Content Negotiation in HTTP. RFC 2295, HTTP Working Group, March 1998.

No context found.

Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP. RFC 2295, March 1998.

No context found.

K. Holtman and A. Mutz, "Transparent Content Negotiation in HTTP" IETF RFC 2295, 1998.

No context found.

Holtman K, and Mutz A (1998) Transparent content negotiation in HTTP. IETF Network Working Group, RFC 2295, 1998

No context found.

K. Holtman and A. Mutz. Transparent content negotiation in http. RFC 2295, IETF, 1998.

No context found.

Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.

No context found.

Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.

No context found.

Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.

No context found.

K. Holtman and A. Mutz. Transparent content negotiation in http. RFC 2295, IETF, 1998.

No context found.

Holtman, K., and A. Mutz, "Transparent Content Negotiation in HTTP", Work in Progress.

No context found.

Holtman K., and Mutz (1998). A. Transparent Content Negotiation in HTTP. RFC2295. http://www.ietf.org/rfc/rfc2295.txt?number=2295.

No context found.

Holtman K., and Mutz (1998). A. Transparent Content Negotiation in HTTP. RFC2295. http://www.ietf.org/rfc/rfc2295.txt?number=2295.

No context found.

Holtman K, and Mutz A (1998) Transparent content negotiation in HTTP. IETF Network Working Group, RFC 2295, 1998

No context found.

Holtman K., TUE and Mutz A. Transparent Content Negotiation in HTTP. RFC 2295, Network Working Group, March 1998.

No context found.

Holtman, K., and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.

No context found.

Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998

No context found.

Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.

No context found.

Holtman K., TUE and Mutz A. Transparent Content Negotiation in HTTP. RFC 2295, Network Working Group, March 1998.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC