■ The Internet Engineering Task Force (IETF) defined not only the basic transfer protocols that make the Internet a reality, but also a number of applicationlevel protocols, including protocols for e-mail, file transfer, and the World Wide Web. However, the area of printing over the Internet has so far not been addressed. This was the most obvious reason for initiating the Internet Printing Protocol (IPP) project. Another major reason was that several vendors had started to work on their own proprietary solutions for web-based printing, which would have meant competing de facto solutions that would probably not have been able to interoperate. This article gives you some historic background on earlier printing standards and describes some of the development processes and choices that the project had to make in order to come up with solutions that meet most of the requirements without being too complex. It describes the major steps that we went through, and introduces a number of the people who contributed to the development of the IPP. he history of printing standards has two separate starting points:
{"title":"The birth of the Internet printing protocol (IPP)","authors":"C. Manros","doi":"10.1145/338183.338184","DOIUrl":"https://doi.org/10.1145/338183.338184","url":null,"abstract":"■ The Internet Engineering Task Force (IETF) defined not only the basic transfer protocols that make the Internet a reality, but also a number of applicationlevel protocols, including protocols for e-mail, file transfer, and the World Wide Web. However, the area of printing over the Internet has so far not been addressed. This was the most obvious reason for initiating the Internet Printing Protocol (IPP) project. Another major reason was that several vendors had started to work on their own proprietary solutions for web-based printing, which would have meant competing de facto solutions that would probably not have been able to interoperate. This article gives you some historic background on earlier printing standards and describes some of the development processes and choices that the project had to make in order to come up with solutions that meet most of the requirements without being too complex. It describes the major steps that we went through, and introduces a number of the people who contributed to the development of the IPP. he history of printing standards has two separate starting points:","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"70 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125888951","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
■ Network externalities are the effects on the value of a product that can be ascribed to the presence of a network of users of such a product. They play an essential role in the business success of any product. The authors think that their role is even larger in the software industry, where (a) documentation and effective training are often lacking, and (b) consumers regard interoperability and compatibility as major benefits because of the ever-increasing need to share information and reprocess it over and over again with different tools. However, only few studies exist on this topic. Network externalities are caused by choices operating at different levels of product design data format, GUI metaphors, keyboard sequences, API, and so on. Understanding and planning their presence in a product is difficult. However, the ability to manipulate them properly provides a clear competitive advantage. This article briefly reviews the literature on network externalities, outlines a graphic notation to represent them, and applies such notation to describe an example, that of Microsoft Word 97. The study of the network externalities in Microsoft Word 97 shows several different kinds. The authors focus on the data format, the API, and the human-computer interaction paradigm. irms aim at maximizing the “value” of their products. However, the notion of value is hard to qualify and quantify. The hedonic model represents the value of a product as the sum of the values of the different components of the product [Berndt 1991]. The hedonic model has already been applied to software products in Gandal [1994]. In this paper we assume an hedonic model for the composition of the value of a product, and we cluster the components of the value into “internal” and “external.” Internal components depend on the product per se, that is, its functionality, its usability, its reliability, and so on. External components depend on the environment in which the product is located. The environment is formed by the users of the product and by other complementary or competing products. For instance, the value of e-mail service depends on the internal features of the service—availability, reliability, speed, and maximum size of the mailbox— and also on the environment, i.e., how many people we can reach using such a service. A service can supply the fastest connection or the largest mailbox, but if we cannot reach the people we want, the value we attach to the service is zero. Several researchers have investigated the value of internal components; see for example Boehm [1984] and Putnam and Myers [1992]. External components are usually called “network externalities,” since they are the result of a network of users of products and of complementary products [Farrell and Saloner 1985]. The authors think that network externalities play a strategic role in the software industry because:
■网络外部性是对产品价值的影响，这种影响可以归因于该产品的用户网络的存在。它们在任何产品的商业成功中都起着至关重要的作用。作者认为他们在软件行业中的作用甚至更大，其中(a)文档和有效的培训经常缺乏，(b)消费者认为互操作性和兼容性是主要的好处，因为不断增加的需要共享信息，并使用不同的工具一次又一次地对其进行再处理。然而，关于这一主题的研究很少。网络外部性是由在产品设计数据格式、GUI隐喻、键盘序列、API等不同层次上操作的选择引起的。理解和规划它们在产品中的存在是很困难的。然而，正确操作它们的能力提供了一个明显的竞争优势。本文简要回顾了有关网络外部性的文献，概述了一种图形符号来表示它们，并应用这种符号来描述一个例子，即Microsoft Word 97。对microsoftword97中网络外部性的研究显示了几种不同的外部性。作者着重于数据格式、API和人机交互范例。公司的目标是使其产品的“价值”最大化。然而，价值的概念很难限定和量化。享乐模型将产品的价值表示为产品的不同组成部分的价值总和[Berndt 1991]。甘达尔[1994]已经将享乐模型应用于软件产品。在本文中，我们假设了一个产品价值构成的享乐模型，并将价值组成分为“内部”和“外部”。内部组件依赖于产品本身，即它的功能、可用性、可靠性等等。外部组件取决于产品所处的环境。环境是由产品的用户和其他互补或竞争的产品形成的。例如，电子邮件服务的价值取决于服务的内部特性——可用性、可靠性、速度和邮箱的最大大小——还取决于环境，即我们可以使用这种服务联系到多少人。一项服务可以提供最快的连接或最大的邮箱，但如果我们不能联系到我们想要的人，我们赋予这项服务的价值就是零。几位研究人员调查了内部成分的价值;参见Boehm[1984]和Putnam and Myers[1992]。外部组件通常被称为“网络外部性”，因为它们是产品和互补产品的用户网络的结果[Farrell和Saloner 1985]。作者认为，网络外部性在软件产业中扮演着战略性的角色，因为:
{"title":"Network externalities in software systems","authors":"G. Succi, P. Predonzani, A. Valerio, T. Vernazza","doi":"10.1145/338183.338194","DOIUrl":"https://doi.org/10.1145/338183.338194","url":null,"abstract":"■ Network externalities are the effects on the value of a product that can be ascribed to the presence of a network of users of such a product. They play an essential role in the business success of any product. The authors think that their role is even larger in the software industry, where (a) documentation and effective training are often lacking, and (b) consumers regard interoperability and compatibility as major benefits because of the ever-increasing need to share information and reprocess it over and over again with different tools. However, only few studies exist on this topic. Network externalities are caused by choices operating at different levels of product design data format, GUI metaphors, keyboard sequences, API, and so on. Understanding and planning their presence in a product is difficult. However, the ability to manipulate them properly provides a clear competitive advantage. This article briefly reviews the literature on network externalities, outlines a graphic notation to represent them, and applies such notation to describe an example, that of Microsoft Word 97. The study of the network externalities in Microsoft Word 97 shows several different kinds. The authors focus on the data format, the API, and the human-computer interaction paradigm. irms aim at maximizing the “value” of their products. However, the notion of value is hard to qualify and quantify. The hedonic model represents the value of a product as the sum of the values of the different components of the product [Berndt 1991]. The hedonic model has already been applied to software products in Gandal [1994]. In this paper we assume an hedonic model for the composition of the value of a product, and we cluster the components of the value into “internal” and “external.” Internal components depend on the product per se, that is, its functionality, its usability, its reliability, and so on. External components depend on the environment in which the product is located. The environment is formed by the users of the product and by other complementary or competing products. For instance, the value of e-mail service depends on the internal features of the service—availability, reliability, speed, and maximum size of the mailbox— and also on the environment, i.e., how many people we can reach using such a service. A service can supply the fastest connection or the largest mailbox, but if we cannot reach the people we want, the value we attach to the service is zero. Several researchers have investigated the value of internal components; see for example Boehm [1984] and Putnam and Myers [1992]. External components are usually called “network externalities,” since they are the result of a network of users of products and of complementary products [Farrell and Saloner 1985]. The authors think that network externalities play a strategic role in the software industry because:","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"93 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127019616","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
■ Compatibility is a key strategic decision in software production. Proposals exist for standards in several fields of software production, such as networking (ISO and IEEE), operating systems (Posix), and object management (OMG). However, a formal treatment of standards in software is still missing. This article tries to overcome this lack, presenting a model of the effects of compatibility in software production. It overviews existing work on compatibility; details a model on the effects of compatibility decisions in software development; and describes the application of this model to new products being introduced and to well-established incumbents. ompatibility is a key strategic decision in software production, in particular when the software development process is based on domain analysis and reuse. For some years software firms have been facing process improvement and product quality issues. However, few are conscious of the role of market structure in their operations. Often “experts,” following rules of thumb, perform the analysis of the application. They aim at identifying feasibility and potential return on investment, but usually do not consider in depth aspects related to market structure, such as compatibility and consumer network effects. Proposals exist for standards in several fields of software production, such as networking (ISO and IEEE), operating systems (Posix), and object management (OMG). However, a formal treatment of standards in software is still missing. This article describes a mathematical model of the effects of compatibility on software production and discusses the application of this model in different scenarios. Papers by Matutes and Regibeau [1988; 1992] are the base; references are also made to the proposals of Farrell and Saloner [1985; 1986] and to Katz and Shapiro [1985]. This paper is organized as follows. A review of the existing approaches is presented in Section 1. Section 2 proposes a framework to determine the effects of standards in software production. Section 3 analyses the conclusions coming from the application of the framework. Section 4 draws some conclusions and outlines future directions of this research.
{"title":"Compatibility, standards, and software production","authors":"G. Succi, A. Valerio, T. Vernazza, G. Succi","doi":"10.1145/338183.338185","DOIUrl":"https://doi.org/10.1145/338183.338185","url":null,"abstract":"■ Compatibility is a key strategic decision in software production. Proposals exist for standards in several fields of software production, such as networking (ISO and IEEE), operating systems (Posix), and object management (OMG). However, a formal treatment of standards in software is still missing. This article tries to overcome this lack, presenting a model of the effects of compatibility in software production. It overviews existing work on compatibility; details a model on the effects of compatibility decisions in software development; and describes the application of this model to new products being introduced and to well-established incumbents. ompatibility is a key strategic decision in software production, in particular when the software development process is based on domain analysis and reuse. For some years software firms have been facing process improvement and product quality issues. However, few are conscious of the role of market structure in their operations. Often “experts,” following rules of thumb, perform the analysis of the application. They aim at identifying feasibility and potential return on investment, but usually do not consider in depth aspects related to market structure, such as compatibility and consumer network effects. Proposals exist for standards in several fields of software production, such as networking (ISO and IEEE), operating systems (Posix), and object management (OMG). However, a formal treatment of standards in software is still missing. This article describes a mathematical model of the effects of compatibility on software production and discusses the application of this model in different scenarios. Papers by Matutes and Regibeau [1988; 1992] are the base; references are also made to the proposals of Farrell and Saloner [1985; 1986] and to Katz and Shapiro [1985]. This paper is organized as follows. A review of the existing approaches is presented in Section 1. Section 2 proposes a framework to determine the effects of standards in software production. Section 3 analyses the conclusions coming from the application of the framework. Section 4 draws some conclusions and outlines future directions of this research.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"46 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127933525","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
■ As a generic software module, IPP software may be embedded in applications, printers, scanners, other rendering devices, and in operating systems. As IPP becomes more widespread, we can expect operating systems vendors to add IPP capabilities to their operating systems. Linux has become increasingly popular as a server operating system of choice because of its open source nature. With Linux’s excellent management and communications infrastructure, having an implementation of the Internet Printing Protocol will allow IS managers to provide a unifying interface for printers. A low-cost PC running Linux, with a parallel printer connected to it, may serve as an IPP server for printers without IPP firmware. It can provide additional functionality otherwise not present in low-cost printers, such as accounting and security. Since Linux scales well, the same software can be used for high-end systems with multiple printers and extended capabilities. Although this article focuses on implementation of IPP on Linux, most of the facts, concepts, and implementation strategies described here are not specific to Linux, but are similar to other Unix-like operating systems, such as FreeBSD or Solaris, and, to a great degree, to Windows NT and Windows 9X. The tools and utilities can also run on Windows NT, Windows 9X, and could be compiled to run on other operating systems such as Mac or OS/2. Guidelines for implementing IPP clients and servers are part of the IPP RFC series mentioned at the end of this article. PP Server The motivation behind the implementation of an IPP server for operating systems such as Linux is driven by a need to do printing from any client to any printer on the Internet or an Intranet. Placing IPP server software on Linux can provide IPP support for printers that don’t directly support IPP—for almost all printers manufactured so far.
{"title":"Implementing an IPP client and server for Linux","authors":"P. Michalek, M. Sweet","doi":"10.1145/338183.338190","DOIUrl":"https://doi.org/10.1145/338183.338190","url":null,"abstract":"■ As a generic software module, IPP software may be embedded in applications, printers, scanners, other rendering devices, and in operating systems. As IPP becomes more widespread, we can expect operating systems vendors to add IPP capabilities to their operating systems. Linux has become increasingly popular as a server operating system of choice because of its open source nature. With Linux’s excellent management and communications infrastructure, having an implementation of the Internet Printing Protocol will allow IS managers to provide a unifying interface for printers. A low-cost PC running Linux, with a parallel printer connected to it, may serve as an IPP server for printers without IPP firmware. It can provide additional functionality otherwise not present in low-cost printers, such as accounting and security. Since Linux scales well, the same software can be used for high-end systems with multiple printers and extended capabilities. Although this article focuses on implementation of IPP on Linux, most of the facts, concepts, and implementation strategies described here are not specific to Linux, but are similar to other Unix-like operating systems, such as FreeBSD or Solaris, and, to a great degree, to Windows NT and Windows 9X. The tools and utilities can also run on Windows NT, Windows 9X, and could be compiled to run on other operating systems such as Mac or OS/2. Guidelines for implementing IPP clients and servers are part of the IPP RFC series mentioned at the end of this article. PP Server The motivation behind the implementation of an IPP server for operating systems such as Linux is driven by a need to do printing from any client to any printer on the Internet or an Intranet. Placing IPP server software on Linux can provide IPP support for printers that don’t directly support IPP—for almost all printers manufactured so far.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"2 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128390451","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
■ The Internet has become more than just a network—it is a distributed computing environment. And, like all robust computing environments, printing is an essential element of the environment. Given the increased sophistication of network printers, there is an ever-increasing need to find instances of printers and printing services, to submit and manage print jobs, and control the logical and physical devices within the network. To that end, the Internet Engineering Task Force (IETF) chartered a working group to define an Internet Printing Protocol (IPP). he network printing experts who formed the IPP working group realized that, within an environment like the Internet, there would be a diverse and heterogeneous set of users, systems, drivers, applications, spoolers, connectivity solutions, devices, and page description languages. Given such a complex set of existing, realworld solutions, the working group members recognized that they would not be successful if they simply ratified an “all inclusive” protocol that supported the loose union of a disjointed set of interfaces, parameters, options, and features. Even though the result might become a standard on paper, there would be, in all practicality, no widespread interoperability. In order to solve this problem, the working group went to great lengths to focus on defining a simple, abstract model that could be used to represent the various and diverse systems and implementations that would be used as the backbone for developing and deploying a standard Internet protocol for printing. The IPP model is centered around the roles and interactions of print service users and printer service providers. The print service users (e.g., clients, applications, printer drivers, report generators) cooperate and interact with print service providers (e.g., physical devices, logical devices, spoolers). The model is simple, yet at the same time, is able to support the many underlying configurations of complex, “n-tier” client/server printing solutions. An important simplifying step in the IPP model is to expose only the key objects and interfaces required for the most basic print jobs. Since many “heavyweight”, technically superior solutions have been overtaken by simpler, “lightweight” easier-to-implement solutions, the IPP model tends to lean toward simplicity rather than completeness. Like the acceptance and growth of HTTP with its many subsequent revisions, many members of the working group knew that they would rather have the problem of needing to enhance a successfully deployed, ubiquitous printing protocol than be “all dressed up with nowhere to go.” This article describes the model elements and operational semantics that form the foundation of IPP. FIGURE 1
{"title":"A model for Internet printing","authors":"Scott A. Isaacson","doi":"10.1145/338183.338186","DOIUrl":"https://doi.org/10.1145/338183.338186","url":null,"abstract":"■ The Internet has become more than just a network—it is a distributed computing environment. And, like all robust computing environments, printing is an essential element of the environment. Given the increased sophistication of network printers, there is an ever-increasing need to find instances of printers and printing services, to submit and manage print jobs, and control the logical and physical devices within the network. To that end, the Internet Engineering Task Force (IETF) chartered a working group to define an Internet Printing Protocol (IPP). he network printing experts who formed the IPP working group realized that, within an environment like the Internet, there would be a diverse and heterogeneous set of users, systems, drivers, applications, spoolers, connectivity solutions, devices, and page description languages. Given such a complex set of existing, realworld solutions, the working group members recognized that they would not be successful if they simply ratified an “all inclusive” protocol that supported the loose union of a disjointed set of interfaces, parameters, options, and features. Even though the result might become a standard on paper, there would be, in all practicality, no widespread interoperability. In order to solve this problem, the working group went to great lengths to focus on defining a simple, abstract model that could be used to represent the various and diverse systems and implementations that would be used as the backbone for developing and deploying a standard Internet protocol for printing. The IPP model is centered around the roles and interactions of print service users and printer service providers. The print service users (e.g., clients, applications, printer drivers, report generators) cooperate and interact with print service providers (e.g., physical devices, logical devices, spoolers). The model is simple, yet at the same time, is able to support the many underlying configurations of complex, “n-tier” client/server printing solutions. An important simplifying step in the IPP model is to expose only the key objects and interfaces required for the most basic print jobs. Since many “heavyweight”, technically superior solutions have been overtaken by simpler, “lightweight” easier-to-implement solutions, the IPP model tends to lean toward simplicity rather than completeness. Like the acceptance and growth of HTTP with its many subsequent revisions, many members of the working group knew that they would rather have the problem of needing to enhance a successfully deployed, ubiquitous printing protocol than be “all dressed up with nowhere to go.” This article describes the model elements and operational semantics that form the foundation of IPP. FIGURE 1","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115492950","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
■ Background: What is TES? The Printer Working Group (PWG) is an open consortium of organizations interested in making printing work better. These organizations represent various aspects of the printing industry. There are representatives of operating systems vendors, print services solution providers, and printer manufacturers. The PWG has a number of projects. One of them is the Internet Printing Protocol (IPP) is organized into a number of subgroups to manage various tasks in the development of the IPP specification. Among these groups are those that oversee the IPP Protocol and IPP Object Model. Another group facilitates IPP prototyping and testing. The designation for this IPP group is TES. TES GOALS he objective of TES is to help anyone implementing IPP; it acts as a central resource for implementers. One goal of IPP TES is to get independent implementations of IPP together. TES uses the IPP mailing list to allow implementers to find each other. Private lists of implementers are maintained. A balance must be maintained between the privacy needs of IPP implementers and the need for implementers to find each other. Another goal is to make IPP tools available to the IPP implementers’ community. Various individuals have donated tools useful for implementing and testing IPP implementation. The benefit gained by such donors is having their tools exercised and debugged by a larger population. TES also takes on the organization of interoperability tests for implementers of IPP. These tests, called “bake-offs,” are not competitive events, but gatherings of IPP implementers and their implementations. The primary goal of TES is to help the development of IPP by putting the specification words to the test. One thing has become quite clear: when the same code base is used for an IPP printer and an IPP client, interoperability is high. There is also agreement on the meaning of ambiguity in the IPP specification. When different code bases are used, misunderstandings are revealed.
{"title":"Interoperability testing for the Internet printing protocol","authors":"Peter Zehler","doi":"10.1145/338183.338192","DOIUrl":"https://doi.org/10.1145/338183.338192","url":null,"abstract":"■ Background: What is TES? The Printer Working Group (PWG) is an open consortium of organizations interested in making printing work better. These organizations represent various aspects of the printing industry. There are representatives of operating systems vendors, print services solution providers, and printer manufacturers. The PWG has a number of projects. One of them is the Internet Printing Protocol (IPP) is organized into a number of subgroups to manage various tasks in the development of the IPP specification. Among these groups are those that oversee the IPP Protocol and IPP Object Model. Another group facilitates IPP prototyping and testing. The designation for this IPP group is TES. TES GOALS he objective of TES is to help anyone implementing IPP; it acts as a central resource for implementers. One goal of IPP TES is to get independent implementations of IPP together. TES uses the IPP mailing list to allow implementers to find each other. Private lists of implementers are maintained. A balance must be maintained between the privacy needs of IPP implementers and the need for implementers to find each other. Another goal is to make IPP tools available to the IPP implementers’ community. Various individuals have donated tools useful for implementing and testing IPP implementation. The benefit gained by such donors is having their tools exercised and debugged by a larger population. TES also takes on the organization of interoperability tests for implementers of IPP. These tests, called “bake-offs,” are not competitive events, but gatherings of IPP implementers and their implementations. The primary goal of TES is to help the development of IPP by putting the specification words to the test. One thing has become quite clear: when the same code base is used for an IPP printer and an IPP client, interoperability is high. There is also agreement on the meaning of ambiguity in the IPP specification. When different code bases are used, misunderstandings are revealed.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"15 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124772585","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
■ This article discusses the encoding of IPP and overall transport using HTTP and TCP/IP. It describes the IPP protocol elements, mapping of IPP to the wire, pros and cons of using HTTP to transfer IPP and various implementation considerations. PP is operations encoding and format coupled with an application-level protocol developed to address modern, distributed printing using existing Internet technologies. The IPP protocol consists of request and response messages. IPP clients send request messages to IPP printers and get response messages back in return. The request message consists of an IPP operation code, attributes and (optionally) print data. IPP response messages consist of a status code and attributes. IPP request/ response message encoding is referred to as the “operation layer” and forms a new Internet MIME media type called “application/ipp.” The IPP operation layer is transport-independent and, as such, requires some application-layer means of transfer. The first widespread, standardized embodiment of IPP is based on the use of HTTP1.1 as the transfer protocol. In this context, printing with IPP consists of a series of HTTP posts, generated by the IPP client, and appropriate responses from the IPP printer. The ability for HTTP to encapsulate the print data stream and represent printer and print job objects as URIs meets the requirements of the IPP operation layer. Furthermore, the ability for HTTP/1.1 to manage print data as a sequence of chunks, each with a known length, makes it ideal for a wide range of print applications where the total length of the data is not known prior to submission. To distinguish the use of HTTP with IPP vs. generic browsing, the Internet Assigned Numbers Authority (IANA) has assigned the well-known port 631, which is considered the default port for IPP over HTTP. Implementations may support additional ports (including port 80). An actual IPP URL scheme (ipp://) is under consideration for future versions of the IPP standard to further distinguish the role of HTTP in printing.
{"title":"Internet printing protocol (IPP) encoding and transport","authors":"C. Kugler, H. Lewis","doi":"10.1145/338183.338188","DOIUrl":"https://doi.org/10.1145/338183.338188","url":null,"abstract":"■ This article discusses the encoding of IPP and overall transport using HTTP and TCP/IP. It describes the IPP protocol elements, mapping of IPP to the wire, pros and cons of using HTTP to transfer IPP and various implementation considerations. PP is operations encoding and format coupled with an application-level protocol developed to address modern, distributed printing using existing Internet technologies. The IPP protocol consists of request and response messages. IPP clients send request messages to IPP printers and get response messages back in return. The request message consists of an IPP operation code, attributes and (optionally) print data. IPP response messages consist of a status code and attributes. IPP request/ response message encoding is referred to as the “operation layer” and forms a new Internet MIME media type called “application/ipp.” The IPP operation layer is transport-independent and, as such, requires some application-layer means of transfer. The first widespread, standardized embodiment of IPP is based on the use of HTTP1.1 as the transfer protocol. In this context, printing with IPP consists of a series of HTTP posts, generated by the IPP client, and appropriate responses from the IPP printer. The ability for HTTP to encapsulate the print data stream and represent printer and print job objects as URIs meets the requirements of the IPP operation layer. Furthermore, the ability for HTTP/1.1 to manage print data as a sequence of chunks, each with a known length, makes it ideal for a wide range of print applications where the total length of the data is not known prior to submission. To distinguish the use of HTTP with IPP vs. generic browsing, the Internet Assigned Numbers Authority (IANA) has assigned the well-known port 631, which is considered the default port for IPP over HTTP. Implementations may support additional ports (including port 80). An actual IPP URL scheme (ipp://) is under consideration for future versions of the IPP standard to further distinguish the role of HTTP in printing.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"9 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131630774","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
■ In the Beginning . . . For almost as long as there have been computers, there have been people working on standards for them. Computer designers and users soon realized that a computer by itself had a limited number of uses; computers need to communicate with other computers and with peripherals such as storage, input, and output devices. ommunication and networking standards groups like the Internet Engineering Task Force (IETF) have focused much more on the exchange of data between computers and the management of the computer and network infrastructure than on communications with peripherals. While the Internet Printing Protocol is currently defined as “experimental” by the IETF, it is expected to move to the “standards track” in the near future. When that happens, it will become the first “standards track” printing protocol. (RFC1179, “Line Printer Daemon Protocol,” is an informational document.) The working group, composed of leaders in the printer and printing industries, spent much of its time early in the process developing a design goals or requirements document. That document was then used as a benchmark to assess the validity of design decisions.
{"title":"Requirements and design goals for an Internet printing protocol","authors":"F. D. Wright","doi":"10.1145/338183.338191","DOIUrl":"https://doi.org/10.1145/338183.338191","url":null,"abstract":"■ In the Beginning . . . For almost as long as there have been computers, there have been people working on standards for them. Computer designers and users soon realized that a computer by itself had a limited number of uses; computers need to communicate with other computers and with peripherals such as storage, input, and output devices. ommunication and networking standards groups like the Internet Engineering Task Force (IETF) have focused much more on the exchange of data between computers and the management of the computer and network infrastructure than on communications with peripherals. While the Internet Printing Protocol is currently defined as “experimental” by the IETF, it is expected to move to the “standards track” in the near future. When that happens, it will become the first “standards track” printing protocol. (RFC1179, “Line Printer Daemon Protocol,” is an informational document.) The working group, composed of leaders in the printer and printing industries, spent much of its time early in the process developing a design goals or requirements document. That document was then used as a benchmark to assess the validity of design decisions.","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"77 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-12-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132353576","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
■ Are you a busy person, with little time to go to stores? If you need a present for your brother-in-law, want to go to a spa, want the best deal on travel, want to comparison shop for a car, it’s all there on the Internet. lectronic commerce, or e-commerce, is changing the way the world shops. Electronic commerce is defined here as browser-based sites created for the purpose of selling goods and services over the Internet, regardless of whether the actual sale takes place on the Internet or via fax, phone, or another means provided by the website. The electronic commerce market is exploding at a remarkable rate. In May 1997, global e-commerce generated $750 million in sales; in May 1998 that figure had grown to $2.3 billion, a 205% increase [IDC 1998]. IDC, ActiveMedia, and Forrester Research all estimate that global commerce revenues will exceed one trillion dollars by 2003. A key to achieving these numbers is usability. In order to leverage this new marketing strategy, companies must understand how to create usable e-commerce sites based on their target markets. In a recent survey, 8% of those surveyed said they don’t shop online simply because the sites are too hard to use [Herschlag 1998]. Electronic shopping has some key differences from physical shopping. First, it is easy to go from one site to another for purposes of price comparison, product selection, and ease of finding the product. There is minimal overhead for changing sites, unlike getting back in the car and driving a distance to a similar store, so sites that offer a range of products that are easy to find on the site and priced competitively will do well. Companies spend substantial amounts of money on physical store design and on creating a positive environment and experience for the shopper. Since ecommerce sites are more limited (the shopper’s general environment doesn’t change), companies must try harder to create a pleasant experience. The factors that are known to affect customer behavior—product perception, shopping experience, and customer service—must be given consideration when designing the site. (For more information on this see Jarvenpaa and Todd [1997].) E-commerce sites are not just web sites—they should reflect the same value-to-price trade-offs that the company has built its business on. A company also has to give serious thought to how much they will support international sales. Will such sales be in US dollars only, or in multiple currencies?
{"title":"Creating usable e-commerce sites","authors":"J. Rohn","doi":"10.1145/324042.324046","DOIUrl":"https://doi.org/10.1145/324042.324046","url":null,"abstract":"■ Are you a busy person, with little time to go to stores? If you need a present for your brother-in-law, want to go to a spa, want the best deal on travel, want to comparison shop for a car, it’s all there on the Internet. lectronic commerce, or e-commerce, is changing the way the world shops. Electronic commerce is defined here as browser-based sites created for the purpose of selling goods and services over the Internet, regardless of whether the actual sale takes place on the Internet or via fax, phone, or another means provided by the website. The electronic commerce market is exploding at a remarkable rate. In May 1997, global e-commerce generated $750 million in sales; in May 1998 that figure had grown to $2.3 billion, a 205% increase [IDC 1998]. IDC, ActiveMedia, and Forrester Research all estimate that global commerce revenues will exceed one trillion dollars by 2003. A key to achieving these numbers is usability. In order to leverage this new marketing strategy, companies must understand how to create usable e-commerce sites based on their target markets. In a recent survey, 8% of those surveyed said they don’t shop online simply because the sites are too hard to use [Herschlag 1998]. Electronic shopping has some key differences from physical shopping. First, it is easy to go from one site to another for purposes of price comparison, product selection, and ease of finding the product. There is minimal overhead for changing sites, unlike getting back in the car and driving a distance to a similar store, so sites that offer a range of products that are easy to find on the site and priced competitively will do well. Companies spend substantial amounts of money on physical store design and on creating a positive environment and experience for the shopper. Since ecommerce sites are more limited (the shopper’s general environment doesn’t change), companies must try harder to create a pleasant experience. The factors that are known to affect customer behavior—product perception, shopping experience, and customer service—must be given consideration when designing the site. (For more information on this see Jarvenpaa and Todd [1997].) E-commerce sites are not just web sites—they should reflect the same value-to-price trade-offs that the company has built its business on. A company also has to give serious thought to how much they will support international sales. Will such sales be in US dollars only, or in multiple currencies?","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"34 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122980785","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
s Selling goods and services successfully over the Internet requires all of the skills and ingenuity of a shopkeeper plus a basic and evolving understanding of local and international laws, regulations , and behavior patterns, which seem to be in a long-term rapid development cycle and thus require close attention. Electronic shopkeepers and those who support them do well to watch domestic and international developments in the following seven areas of particularly fast-paced change: ● privacy ● security ● intellectual property ● localization/internationalization ● taxation ● export/import ● usability he articles in this issue of StandardView were selected to explore some of these seven areas in detail. Not all of the areas could be addressed; e-commerce is still very much in development and, while experience is getting more common, expertise is rare. Several of the areas have yet to establish formal standards that specifically apply to e-commerce; for others, standards are either newly available or are just being drafted. Each area will see extraordinary activity in the near future toward discussing, creating, or evolving de facto or de jure standards. In addition to these developing areas, existing and broader standards, such as XML, TickIT, and ISO9000, are being applied to e-commerce. There are many definitions for e-commerce. The working definition for this article isϺ " any commercial transaction that starts or ends with the Internet. " Any product, whether physical or electronic, can be sold using e-commerce mechanisms. E-commerce includes: ● electronic distribution with electronic sales and telesales ● free, prerelease, and released products ● product fixes and upgrades ● try-and-buy electronic software distribution ● electronic ordering with physical fulfillment ● electronic sales of subscriptions ● electronic marketing with telesales follow-up ● free and lower-cost distribution to educational customers ● business-to-consumer ● business-to-business
{"title":"Keeping an electronic commerce shop","authors":"Katy Dickinson","doi":"10.1145/324042.324045","DOIUrl":"https://doi.org/10.1145/324042.324045","url":null,"abstract":"s Selling goods and services successfully over the Internet requires all of the skills and ingenuity of a shopkeeper plus a basic and evolving understanding of local and international laws, regulations , and behavior patterns, which seem to be in a long-term rapid development cycle and thus require close attention. Electronic shopkeepers and those who support them do well to watch domestic and international developments in the following seven areas of particularly fast-paced change: ● privacy ● security ● intellectual property ● localization/internationalization ● taxation ● export/import ● usability he articles in this issue of StandardView were selected to explore some of these seven areas in detail. Not all of the areas could be addressed; e-commerce is still very much in development and, while experience is getting more common, expertise is rare. Several of the areas have yet to establish formal standards that specifically apply to e-commerce; for others, standards are either newly available or are just being drafted. Each area will see extraordinary activity in the near future toward discussing, creating, or evolving de facto or de jure standards. In addition to these developing areas, existing and broader standards, such as XML, TickIT, and ISO9000, are being applied to e-commerce. There are many definitions for e-commerce. The working definition for this article isϺ \" any commercial transaction that starts or ends with the Internet. \" Any product, whether physical or electronic, can be sold using e-commerce mechanisms. E-commerce includes: ● electronic distribution with electronic sales and telesales ● free, prerelease, and released products ● product fixes and upgrades ● try-and-buy electronic software distribution ● electronic ordering with physical fulfillment ● electronic sales of subscriptions ● electronic marketing with telesales follow-up ● free and lower-cost distribution to educational customers ● business-to-consumer ● business-to-business","PeriodicalId":270594,"journal":{"name":"ACM Stand.","volume":"6 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1998-09-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129480723","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：