DOCSLIB.ORG

Syncml HTTP Binding 1 of 19 Pages Version 1.0 2000-12-07

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Syncml HTTP Binding 1 of 19 Pages Version 1.0 2000-12-07 SyncML HTTP Binding 1 of 19 Pages http://www.syncml.org/docs/syncml_http_v10_20001207.pdf Version 1.0 2000-12-07 SyncML HTTP Binding, version 1.0 Abstract THIS SPECIFICATION IS A SYNCML DRAFT DOCUMENT AND MAY BE UPDATED, REPLACED OR OBSOLETED BY ANOTHER DOCUMENT AT ANY TIME. IT IS INAPPROPRIATE TO USE THIS SPECIFICATION FOR PRODUCT IMPLEMENTATION UNTIL PUBLISHED OR TO REFERENCE THE MATERIAL OR TO CITE IT OTHER THAN AS "WORK IN PROGRESS". This document describes how to use the SyncML over HTTP. The document uses the primitives and methods defined in the HTTP specification V1.1 as defined in [1]. The document assumes a scenario consisting of a data synchronization client (e.g., a mobile phone) and a data synchronization server where the master for the data resides. Within wide area networks, the data synchronization server could be a remote web server. Copyright © Ericsson, IBM, Lotus, Matsushita Communications Industrial Co., LTD, Motorola, Nokia, Palm, Inc., Psion, Starfish Software (2000) All Rights Reserved. SyncML HTTP Binding 2 of 19 Pages http://www.syncml.org/docs/syncml_http_v10_20001207.pdf Version 1.0 2000-12-07 SyncML Initiative The following companies are Sponsors of the SyncML initiative: Ericsson IBM Lotus Matsushita Communications Industrial Co. Motorola Nokia Palm, Inc. Psion Starfish Software Revision History Revision Date Comments V0.9 2000-05-31 Version 0.9. V1.0 2000-08-29 Reformatted for v1.0 Alpha release. No technical changes. Alpha V1.0 Beta 2000-11-10 Revised headers for v1.0 Beta release. No technical changes. V1.0 2000-12-07 The candidate version for the final release. Copyright © Ericsson, IBM, Lotus, Matsushita Communication Industrial Co., LTD, Motorola, Nokia, Palm, Inc., Psion, Starfish Software (2000) All Rights Reserved. SyncML HTTP Binding 3 of 19 Pages http://www.syncml.org/docs/syncml_http_v10_20001207.pdf Version 1.0 2000-12-07 Copyright Notice Copyright (c) Ericsson, IBM, Lotus, Matsushita Communication Industrial Co., LTD, Motorola, Nokia, Palm, Inc., Psion, Starfish Software (2000). All Rights Reserved. Implementation of all or part of any Specification may require licenses under third party intellectual property rights, including without limitation, patent rights (such a third party may or may not be a Supporter). The Sponsors of the Specification are not responsible and shall not be held responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights. THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN ARE PROVIDED ON AN "AS IS" BASIS WITHOUT WARRANTY OF ANY KIND AND ERICSSON, IBM, LOTUS, MATSUSHITA COMMUNICATION INDUSTRIAL CO. LTD, MOTOROLA, NOKIA, PALM INC., PSION, STARFISH SOFTWARE AND ALL OTHER SYNCML SPONSORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL ERICSSON, IBM, LOTUS, MATSUSHITA COMMUNICATION INDUSTRIAL CO., LTD, MOTOROLA, NOKIA, PALM INC., PSION, STARFISH SOFTWARE OR ANY OTHER SYNCML SPONSOR BE LIABLE TO ANY PARTY FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OF BUSINESS, OR FOR DIRECT, INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES OF ANY KIND IN CONNECTION WITH THIS DOCUMENT OR THE INFORMATION CONTAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. The above notice and this paragraph must be included on all copies of this document that are made. Copyright © Ericsson, IBM, Lotus, Matsushita Communication Industrial Co., LTD, Motorola, Nokia, Palm, Inc., Psion, Starfish Software (2000) All Rights Reserved. SyncML HTTP Binding 4 of 19 Pages http://www.syncml.org/docs/syncml_http_v10_20001207.pdf Version 1.0 2000-12-07 Table of Contents 1 Introduction..................................................................................................5 2 Formatting Conventions .............................................................................5 3 Terminology.................................................................................................5 4 HTTP Introduction .......................................................................................8 5 SyncML Binding to HTTP............................................................................8 5.1 TCP Transport Service ....................................................................8 5.1.1 Connection .........................................................................8 5.1.2 Connection Options............................................................8 5.1.3 Disconnection.....................................................................9 5.1.4 Abort...................................................................................9 5.1.5 Timeouts.............................................................................9 5.2 Exchanging SyncML Messages.......................................................9 5.2.1 Single Message Per Package...........................................10 5.2.2 Multiple Messages Per Package ......................................10 5.3 Transport Commands....................................................................11 5.3.1 Methods............................................................................11 5.3.2 General Headers ..............................................................11 5.3.3 Request Headers..............................................................12 5.3.4 Response Headers...........................................................14 5.4 Security..........................................................................................16 6 Examples....................................................................................................16 7 References .................................................................................................19 Copyright © Ericsson, IBM, Lotus, Matsushita Communication Industrial Co., LTD, Motorola, Nokia, Palm, Inc., Psion, Starfish Software (2000) All Rights Reserved. SyncML HTTP Binding 5 of 19 Pages http://www.syncml.org/docs/syncml_http_v10_20001207.pdf Version 1.0 2000-12-07 1 Introduction This document defines the binding requirements for communicating SyncML over the Hypertext Transfer Protocol (HTTP) as defined by [1]. HTTP is an application-level protocol for distributing information between two Internet based applications. HTTP can be an ideal protocol for building wide area, distributed systems, such as the collaborative framework of the World-Wide Web (Web) environment. HTTP is expected to be the primary wireline protocol used by SyncML clients and servers to communicate with each other. In addition, as wireless networks increase in bandwidth (e.g., deployment of GPRS networks) and are adapted to support the IP protocol, HTTP will become the preferred application protocol for connecting wireless SyncML clients and servers. The HTTP protocol defines a request/response form of communication between two network computers supporting HTTP applications. Normally, the originator of the request is called the HTTP client. And normally, the recipient of the request is called the HTTP server. There are emerging Internet standards for notification or "push" technologies that will allow HTTP servers to also originate HTTP requests. However, this technology is not currently included in this version of the specification. HTTP is an ideal protocol for connecting a SyncML client to a SyncML server; and vice a versa. SyncML is intended to be registered as a MIME media type. This makes it adapted for transfer over HTTP. HTTP is widely supported across the Internet. There are numerous examples of common implementations of both client and server HTTP applications. HTTP servers can be adapted to support new HTTP-based application in a straightforward manner. SyncML messages can be transferred across the Internet and pass through "firewalls", at the perimeter of individual intranets with relative ease. 2 Formatting Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interoperated as described in [3]. Any reference to components of the Device Information DTD or XML [5] snipets are specified in this type face. 3 Terminology See [6] and [7] for definitions of SyncML terms used within this specification. The following terms are copied from [1]. Cache A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. Copyright © Ericsson, IBM, Lotus, Matsushita Communication Industrial Co., LTD, Motorola, Nokia, Palm, Inc., Psion, Starfish Software (2000) All Rights Reserved. SyncML HTTP Binding 6 of 19 Pages http://www.syncml.org/docs/syncml_http_v10_20001207.pdf Version 1.0 2000-12-07 Cacheable A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13 of [1]. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the
Load more

Recommended publications
  • Network Working Group M. Thomson Internet-Draft Intended Status: Informational M
    Network Working Group M. Thomson Internet-Draft Intended status: Informational M. Nottingham Expires: March 21, 2020 September 18, 2019 Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) draft-iab-escape-report-00 Abstract The Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 21, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
    [Show full text]
  • Chapter 4: the Hypertext Transfer Protocol (HTTP)
    4. The Hypertext Transfer Protocol 4-1 Chapter 4: The Hypertext Transfer Protocol (HTTP) References: • Erik Wilde: World Wide Web — Technische Grundlagen. Springer, 1999, ISBN 3-540- 64700-7, 641 Seiten. • T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext Transfer Protocol — HTTP/1.0. RFC 1945, May 1996, 60 pages. • R. Fielding et al.: Hypertext Transfer Protocol — HTTP/1.1. RFC 2616, June 1999, 176 pages. • J. Franks et al.: HTTP Authentication: Basic and Digest Access Authentication. RFC 2617, June 1999, 34 pages. • David H. Crocker (Ed.): Standard for the Format of ARPA Internet Text Messages. RFC 822, August 1982, 47 pages. • P. Wainwright: Professional Apache. Wrox Press, 1999, ISBN 1-861003-02-1, 617 pages. • D. Kristol, L. Montulli: HTTP State Management Mechanism. RFC 2965, Oct. 2000, 26 pages. • K. Moore, N. Freed: Use of HTTP State Management. RFC 2964, Oct. 2000, 8 pages. • David M. Kristol: HTTP Cookies: Standards, privacy, and politics. ACM Transactions on Internet Technology (TOIT), Volume 1 , Issue 2 (November 2001), Pages: 151 - 198 • S. Brass: Cookies. In R. Flynn (Ed.): Macmillan Computer Sciences. Macmillan, 2002. Stefan Brass: Grundlagen des World Wide Web Universit¨atHalle, 2006 4. The Hypertext Transfer Protocol 4-2 Objectives After completing this chapter, you should be able to: • explain what exactly happens when you click on a link in a web page. You should be able to write HTTP requests and interpret HTTP responses. Why it is good to keep the TCP connection open for a short time after the response? • explain how language and format are selected. • explain authentication for protected pages.
    [Show full text]
  • Specification of Web Ingest of Meteorological Bulletins in Wis
    SPECIFICATION OF WEB INGEST OF METEOROLOGICAL BULLETINS IN WIS 2013‐07‐10 TOYODA Eizi, JMA 2013‐09‐09 1st revision, TOYODA Eizi, JMA 2013‐12‐24 2nd revision, MIZUSHIMA Hirofumi, JMA INTRODUCTION This document describes a mechanism to ingest meteorological bulletins in WIS via HTTPS (HTTP over TLS)1. The objective is to back up the dissemination of GTS bulletins when the primary way is under interruptions. The purpose and protocol look similar to the Web Data Ingest2 of GTS. The difference is that the present document is intended for automated submission of files accumulating meteorological bulletins, while the Web Data Ingest is designed for human typing on text forms. GENERAL DISCUSSIONS TERMINOLOGY AND REASON FOR PUSH This document discusses “push” type of protocol, in which sender of data initiates the TCP connection. A software sending data is called “client”, and the receiver called “server”. Push protocol can avoid delay due to polling, while the client has to take responsibility to detect error. The HTTP provides PUT and POST methods for push. Between the two methods, PUT is recommended for simplicity. ONE REQUEST PER ONE FILE One HTTP request is used to submit one file with a name. One HTTP response is returned from the server. The client must inspect the response to detect error. The format of the file may be agreed by both parties of communication, but one possibility is a so‐called WMO FTP format3. 1 IETF RFC 2818: “HTTP Over TLS”. http://tools.ietf.org/html/rfc2818 2 Section B, Attachment II‐16 “Procedures for Transmitting and Collecting Meteorological Bulletins on the Internet”, the Manual on Global Telecommunication System, WMO No.
    [Show full text]
  • Http Status Codes
    HTTP STATUS CODES This is a list of Hypertext Transfer Protocol (HTTP) response status codes. 1XX Informational responses An informational response indicates that the request was received and understood. It is issued on a provisional basis while request processing continues. It alerts the client to wait for a final response. The message consists only of the status line and optional header fields, and is terminated by an empty line. As the HTTP/1.0 standard did not define any 1xx status codes, servers must not[note 1] send a 1xx response to an HTTP/1.0 compliant client except under experimental conditions.[4] 100 Continue The server has received the request headers and the client should proceed to send the request body (in the case of a request for which a body needs to be sent; for example, a POST request). Sending a large request body to a server after a request has been rejected for inappropriate headers would be inefficient. To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. The response 417 Expectation Failed indicates the request should not be continued.[2] 101 Switching Protocols The requester has asked the server to switch protocols and the server has agreed to do so.[5] 102 Processing (WebDAV; RFC 2518) A WebDAV request may contain many sub-requests involving file operations, requiring a long time to complete the request. This code indicates that the server has received and is processing the request, but no response is available yet.[6] This prevents the client from timing out and assuming the request was lost.
    [Show full text]
  • REST-Style API Reference
    DLI REST-style API Reference Generated by Doxygen 20210421T131022Z ii CONTENTS Contents 1 Overview 1 1.1 Target audience............................................ 2 1.2 Design goals.............................................. 2 2 REST architectural style introduction3 2.1 HTTP verbs.............................................. 3 2.2 HTTP request headers ........................................ 4 2.3 Content types............................................. 5 3 Basic examples 5 4 Data model 9 4.1 Scalar types.............................................. 10 4.2 Singleton types ............................................ 10 4.3 Container types............................................ 10 4.4 The sum type ............................................. 11 4.5 The call type.............................................. 11 4.6 Constraints .............................................. 12 5 Supported standard interfaces 12 5.1 URIs.................................................. 12 5.2 HTTP verbs.............................................. 13 5.3 HTTP authentication.......................................... 13 5.4 Input MIME types........................................... 13 5.4.1 application/json........................................ 13 5.4.2 text/plain ........................................... 14 5.4.3 application/x-www-form-urlencoded ............................. 14 5.5 Patch MIME types........................................... 15 5.5.1 application/json-patch+json.................................. 15 5.5.2 application/x-www-form-urlencoded
    [Show full text]
  • An Overview of the HTTP Protocol As Covered in Rfcs 1
    An Overview of the HTTP Protocol as covered in RFCs 1 Contents 1. Introduction and History ........................................................................................................................ 3 2. HTTP Versions ......................................................................................................................................... 3 3. HTTP Protocol Request/Response ......................................................................................................... 3 4. HTTP/1.0 and earlier .............................................................................................................................. 4 5. HTTP Keep-Alive ..................................................................................................................................... 4 6. HTTP Pipelining ....................................................................................................................................... 4 7. HTTP ........................................................................................................................................................ 5 8. HTTP Intermediaries: Proxy ................................................................................................................... 5 9. HTTP Intermediaries: Tunnel ................................................................................................................. 6 10. HTTP Methods .......................................................................................................................................
    [Show full text]
  • Hypertext Transfer Protocol -- HTTP/1.1
    Network Working Group R. Fielding Request for Comments: 2616 UC Irvine Obsoletes: 2068 J. Gettys Category: Standards Track Compaq/W3C J. C. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox P. Leach Microsoft T. Berners-Lee W3C/MIT June, 1999 Hypertext Transfer Protocol -- HTTP/1.1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as “HTTP/1.1”, and is an update to RFC 2068 [33]. Fielding, et al Standards Track [Page 1] RFC 2616 HTTP/1.1 June, 1999 Table of Contents HYPERTEXT TRANSFER PROTOCOL -- HTTP/1.1.................................................1
    [Show full text]