idnits 2.17.1 draft-reddy-ishop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-ishop-00', but the file name used is 'draft-reddy-ishop-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 406 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1: '... EXPIRES: MAY 1998 IN...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (December 01, 1997) is 9642 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 517, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 522, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 526, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 528, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 531, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 533, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 535, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1777 (ref. '1') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1766 (ref. '5') (Obsoleted by RFC 3066, RFC 3282) ** Downref: Normative reference to an Informational RFC: RFC 1898 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Unknown state RFC: RFC 1014 (ref. '8') Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT EXPIRES: MAY 1998 INTERNET-DRAFT 3 Network Working Group R. Reddy 4 Internet-Draft Sharp 5 Dec 1997 09 7 Protocol for shopping over the Internet 8 December 01, 1997 9 11 STATUS OF THIS DOCUMENT 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 ABSTRACT 30 This Internet-Draft specifies a standard method for shopping on the 31 Internet. Using this protocol client programs can enumerate all the 32 products sold by category, search for a particular product and find 33 the cost or quantity of each product. After realizing the cost of a 34 particular product, client programs can compare the price of this 35 product sold on other Internet sites. 37 Table of Contents 39 1. INTRODUCTION 40 2. SCENARIO 41 3. PROTOCOL 42 4. KEY FEATURES 43 4.1 Initializing and closing a connection 44 4.2 Universal Categories 45 4.3 Categories 46 4.4 Products 47 4.5 Search 48 4.6 Compare 49 4.7 Customer Information 50 4.8 Transactions 51 4.9 Other Useful Information 52 4.10 Internet Shopping Protocol Result 53 5. IMPLEMENTATION 54 6. REFERENCES 55 7. AUTHOR'S ADDRESS 57 Expires: May, 1998 [Page 58 1] 60 Internet-Draft 00 Internet Shopping Protocol December 61 1997 63 1. INTRODUCTION 65 Today many companies are advertising their products on the internet, 66 but it is not easy to compare the price of a particular product model 67 sold by different retailers. Since there is no standard protocol to 68 find the attributes of products on the Internet, Customers have to 69 search using a search engine for the keywords of the product. It is 70 very cumbersome to find and compare the prices of the products and it 71 is not possible to easily monitor the prices programmatically. 72 The Internet shopping protocol provides a standard mechanism to get 73 information about the discounts or promotions on different sites. Since 75 there are millions of different products the protocol allows to search 76 by categories. 77 There are a wide variety of products and not all products have the same 79 attributes but mostly all products have some unique identifications. 80 For example books have an ISBN, which uniquely identifies a book, 81 similarly other industries have other unique identifications for most 82 of their products, another example is a model number and a company name 84 together uniquely identify a product. 85 Since different countries use different measurement systems the 86 protocol 87 allows to specify the measurement used. The client programs could 88 convert 89 to any required system depending upon the User's locale. 90 Some products are sold in gallons, some in pounds and some are sold by 91 the dozens, so we should be able to find out about the measurement 92 system used, the three most commonly used measurement systems are MKS 93 (Meter Kilogram Second), FPS (Foot Pound Second), CGS (Centimeter Gram 94 Second) and to make things complicated there is also a mixed 95 measurement 96 which is a combination of all of the above. 97 Since the commerce on the Internet is global, payments for the goods 98 must be made in different currencies in different countries. The 99 protocol allows to specify the choice of currency. Apart from the 100 actual 101 cost of the product there are transaction costs and sales taxes. The 102 Internet shopping protocol provides a uniform mechanism of accessing 103 these values which are crucial for making shopping decisions. 105 Electronic shopping malls can be constructed by browsing products and 106 categories on different Internet sites using the Internet shopping 107 protocol. 109 2. SCENARIO 111 To understand the protocol better, first lets go through a scenario. 112 Lets say a Customer wants to shop for a Fax machine and he/she wants to 114 pay the least price for a particular model. 115 First we need to find all companies selling electronics on the web. 116 The client program must be smart enough to know all the sites which 117 sell 118 different categories of merchandise or we could use the "Directory 119 and Database services" or use LDAP services to locate database servers. 121 Using the above methods lets assume the IShop client program has found 122 14440 companies selling electronics on the Internet. The client program 124 can find out which of the companies support IShop protocol; This can be 126 done by using the host name and the standard port address for IShop. 128 Expires: May, 1998 [Page 129 2] 131 Internet-Draft 00 Internet Shopping Protocol December 132 1997 134 There is no standard port number of Internet shopping at this point but 135 a standard port can be set aside for this purpose. 137 Now lets say we reduced the search to 110 electronic companies which 138 support IShop protocol. 139 Create a socket and obtain a handle for the host server. 140 To find all the local stores. We have to use functions such as 142 ishop_handle3DiShopInitSession(MY_HOST,MY_PORT) 143 getBusinessLocationCity(ishop_handle,string); 144 getUniversalCategories(ishop_handle,category[],0) 146 By using the following operations lets say we further reduced the 147 number 148 of local stores to 10 150 searchCategory(ishop_handle ,"electronics",categoryKey[],1) 151 searchProduct (ishop_handle,categoryKey,"Fax*",productKey[],3) 152 if 153 (myFaxmodelNumber3D=3DgetManufactureProductID(ishop_handle,productKey) 154 getSalePrice(ishop_handle,productKey,money_currency) 155 closeSession(ishop_handle) 157 Using the above operations on other hosts we can find the sale price of 159 the fax machine sold by the different online retailers. If more 160 information is needed, such as discounts, quantity in stock, functions 161 based on Product Key can be used to retrieve the required information. 163 3. PROTOCOL 165 This protocol uses Client/Server paradigm. And the Transport is TCP/IP. 167 If Credit card information has to be transmitted over the network then 168 it is preferable to implement this protocol over Secure Socket Layer 169 (SSL). It is not mandatory to implement all the operations of the 170 protocol. 172 4. KEY FEATURES 174 It is assumed that there is a database file or a database sever on the 175 host server running the IShop server protocol. The protocol is the port 177 of entry for accessing the data in the database. 178 The IShop protocol specifies numerous functions but not all functions 179 are required to be implemented. The functions which are not implemented 181 return functionImplemented 3D false in the ISHOPResult. 182 The result of every function such as its success or failure and other 183 useful information is returned in ISHOPResult. 185 4.1 Initializing and closing a connection 187 ishop_handle 3D iShopInitSession(MY_HOST,MY_PORT) 188 Binding to the host is done in the same call. 189 set the host name, port number to open a connection, no password is 190 required to authenticate the User. 192 ISHOPResult 3D closeSession(ishop_handle) 193 closes the connection. 195 Internet-Draft 00 Internet Shopping Protocol December 196 1997 198 4.2 Universal Categories 200 ISHOPResult 3D getUniversalCategories(ishop_handle,UnvCategory[],count)= 202 count 3D 0 for all universal categories such as books, automobiles, 203 entertainment, medicine, hardware, software, automobiles etc. 205 4.3 Categories 207 ISHOPResult3Dlong getCountCategories(ishop_handle,count) 208 returns count 210 ISHOPResult3DgetCategories(ishop_handle,categoryKey[],count) 211 computer books, cars 213 4.4 Products 215 ISHOPResult3DgetCountProducts(ishop_handle,categoryKey,count) 216 if categoryKey3D0; returns count of all products 218 getProducts(ishop_handle, category, products[],count) 219 if count 3D 0 and category =3D "" returns all products irrespective of = 221 category. Products returned can be product numbers, sku#s or stock 222 numbers etc. any product number unique to the database system. 224 4.5 Search 226 The search operation allows a client to request that a search be 227 performed on its behalf by a server. 229 searchCategory(ishop_handle, "category*",categoryKey[],count) 230 Searching is done on the Server side, wild cards can be used, all 231 searches are case in sensitive. 233 searchProduct(ishop_handle, categoryKey,"product*", productKey[], 234 count) 235 Searching is done on the Server side, wild cards can be used. 237 Expires: May, 1998 [Page 238 4] 240 Internet-Draft 00 Internet Shopping Protocol December 241 1997 243 4.6 Compare 245 Comparison is done on the server on behalf of the client. The result of 247 comparison is returned in ISHOPResult 249 ISHOPResult3DcompareUniverisalCategory(ishop_handle,value) 250 ISHOPResult3DcompareCategory(ishop_handle,value) 251 ISHOPResult3DcompareProduct(ishop_handle,value) 253 value is a TEXT of maximum 100 characters. 255 4.7 Product Details 257 getSalePrice(ishop_handle, productKey, currencyValue) 258 getListPrice(ishop_handle, productKey, currencyValue) 259 getCostPrice(ishop_handle, productKey, currencyValue) 261 getCurrency(ishop_handle, productKey, value) 262 where value is : 13Dus dollar, 2=3Dyen, etc.. 263 Mask bits are used for trading in more than one currency. 264 It is be possible to trade in more than one currency. 266 getProductImage(ishop_handle, productKey,ByteArray) 267 returns a GIF or a JPEG image, returns a byte array, using Base 64. 269 getManufactureProductID(ishop_handle, productKey, IDvalue) 271 could be model number, ISBN, IC number such as 20486, part number etc. 273 getManufacture(ishop_handle, productKey, value) 274 where value (string) is the name of the manufacturer. 276 getUnit(ishop_handle, productKey, unit) 277 where unit(integer) can be denoted as 1 3D lbs, 2 =3D oz, 3 =3D = 278 kilogram, 279 4 3D meter, 5 =3D centimeter, 6 =3D millimeter 281 getQuantity(ishop_handle, productKey, quantity) 282 could be number of boxes etc. returns available quantity (long). 284 getAge(ishop_handle, productKey, age, unit) 285 age 3D double 286 where unit can be denoted as 1 3D Years, 2 =3D Months, 3 =3D Days, 287 4 3D Seconds, 5 =3D Milliseconds etc. 289 getAttributes(ishop_handle, productKey, value) 290 value 3D TEXT of 1024 characters. 291 Unique attributes of the product, in text or an URL. 292 Suppose if the product is a house, then the description of the house is 294 given. 296 Expires: May, 1998 [Page 297 5] 299 Internet-Draft 00 Internet Shopping Protocol December 300 1997 302 getComment(ishop_handle, productKey, text) 303 Merchant's comments and promotions. 305 getDiscount(ishop_handle, productKey, percentage) 306 getPremium(ishop_handle, productKey, percentage) 308 getDescription(ishop_handle, productKey, text) 309 Name of the Product, description must be less than 254 characters 311 getMadeInCountry(ishop_handle, productKey, country[2]) 312 where country is a two letter character array such as US,JP,IN, CN etc. 314 getExpiryDate(ishop_handle, productKey, date) 315 This operation is required to specify if it is a one day garage sale 316 etc. date is a string in the network date format, date also includes 317 time of expiry. 319 getAvailableDate(ishop_handle, productKey, date, value ) 320 date of the event or date when the product will be in stock. 321 value 3D 1 if product is in stock, 2 if product is discontinued, 3 if 322 product is temporarily out of stock. 324 4.8 Business Location 326 Some companies have more than one location. 327 Trading city where all the transactions are handled. 329 getBusinessLocationCity(ishop_handle, value) 331 If you are ordering pizza, it is useful if it is a local store 333 getBusinessLocationStreet(ishop_handle, value) 334 getBusinessCountry(ishop_handle, value) 335 getBusinessZip(ishop_handle, value) 336 getBusinessPhone(ishop_handle, value) 337 getBusinessFax(ishop_handle, value) 338 getSalesRep(ishop_handle, value) 339 getSupervisorEmail(ishop_handle, value) 341 value 3D TEXT of maximum 50 characters. 343 4.9 Customer Information 345 This information is optionally given by the customer 347 setCustomerFirstName(ishop_handle, value) 348 setCustomerLastName(ishop_handle, value) 349 setCustomerStreet(ishop_handle, value) 350 setCustomerCity(ishop_handle, value) 351 setCustomerZip(ishop_handle, value) 353 Expires: May, 1998 [Page 354 6] 356 Internet-Draft 00 Internet Shopping Protocol December 357 1997 359 setCustomerCountry(ishop_handle, value) 360 setCustomerFax(ishop_handle, value) 361 setCustomerPhone(ishop_handle, value) 362 setCustomerEmail(ishop_handle, value) 363 sendPromotionalInfo(ishop_handle, promotion) 365 value 3D TEXT of maximum 50 characters. 366 promotion 3D true/false 368 4.10 SHIPPING ADDRESS 370 setShippingContact(ishop_handle, value) 371 setShippingStreet(ishop_handle, value) 372 setShippingCity(ishop_handle, value) 373 setShippingState(ishop_handle, value) 374 setShippingZip(ishop_handle, value) 375 setShippingInstructions(ishop_handle, value) 377 value 3D TEXT of maximum 50 characters. 379 4.11 Transactions 381 getTrasactionID(ishop_handle, TransactionID ) 383 TransactionID is used to place orders and cancel orders during the 384 current session; Old transaction numbers cannot be obtained using this 385 protocol. Think of the Transaction number as a unique number in the 386 database system. Old Transaction numbers cannot be recycled, a new 387 Transaction must be generated once per every session. The Transaction 388 ID remains a constant and is valid for the entire session. 389 If the connection is lost then all the operations during the session 390 are rolled back. To save the results of any or all operations a session 392 must be successfully closed. Once the session is terminated, Old 393 Transaction Ids cannot be used except for obtaining the transaction 394 status. 396 ISHOPResult 3D AddOrder(ishop_handle, TransactionID,productKey) 397 ISHOPResult 3D CancelOrder(ishop_handle, TransactionID,OrderID) 398 ISHOPResult 3D CancelAllOrders(ishop_handle, TransactionID) 400 orders cannot be cancelled using a previously known Transaction number, 402 however orders placed during the current session can be cancelled. If 403 there is a break in connection during a transaction then the entire 404 transaction must be rolled back. 406 ISHOPResult 3D getTransactionStatus(ishop_handle, TransactionID) 407 Order processed, confirmation, cancelled, shipped date, order date etc. 409 getSalesTax(ishop_handle, orderID) 411 getTransactionCost(ishop_handle, TransactionID) 412 get shipping, handling and other service charges. 414 getTotal(ishop_handle, TransactionID) 416 Expires: May, 1998 [Page 417 7] 419 Internet-Draft 00 Internet Shopping Protocol December 420 1997 422 getReport(ishop_handle, TransactionID, productKey[], 423 description[], cost[]) 425 Detailed report of all the orders successfully placed. A list of 426 Product Key, 427 Description and amount charged for each product. This list does not 428 include 429 sales tax, transaction cost or total sale price, there are other 430 functions 431 to retrieve this kind of information. 433 IShopResult3DBuy(ishop_handle, TransactionID, CreditCardNum, 434 ExpDate, Clearinghouse) 435 The processing can be done by the host server. 436 Merchants can setup the host server to transfer money to there 437 accounts. This 438 operation is optional to the protocol. 440 4.12 Other Useful Information 442 ISHOPResult 3D getIShopVersion(ishop_handle, version) 443 version is a TEXT value of maximum 20 characters 445 ISHOPResult 3D getCharset(ishop_handle, charset) 447 if ascii then charset 3D 1, if ansi then charset =3D2 , if unicode = 448 then 449 charset 3D 3 etc. 450 Allows for databases to be in different languages and character sets. 452 getLanguage(ishop_handle, languageID) 453 The languageID is based on the values given by the Unicode consortium. 455 4.13 Internet Shopping Protocol Result 457 The ISHOPResult is the construct used in this protocol to return 458 success or 459 failure indications from servers to clients. In response to various 460 requests, 461 servers will return responses containing fields of type ISHOPResult to 462 indicate the final status of a protocol operation request. 464 ISHOPResult::3D 465 SEQUENCE { 466 functionImplemented BOOL 467 resultCode ENUMERATED { 468 success (0) 469 operationsError (1) 470 protocolError (2) 471 sizelimitExceeded (3) 472 compareFalse (4) 473 compareTrue (5) 474 busy (50) 475 } 476 OrderID ISHOPString 477 Status ISHOPString 478 errorMessage ISHOPString 479 } 480 ISHOPString depends on the charset used by the Host Server. 482 Expires: May, 1998 [Page 483 8] 485 Internet-Draft 00 Internet Shopping Protocol December 486 1997 488 5. IMPLEMENTATION 490 The above operations can be implemented using SQL on the host 491 side. Depending upon your host server operating environment JDBC, ODBC, 493 ADO (Active database objects), embedded SQL etc. can be used. It is not 495 relevant how the protocol is implemented on the host server, as long as 497 the functions return data, functions not implemented should return a 498 "function implemented 3D false" in ISHOPResult. 500 The IShop protocol is similar to the LDAP protocol, except that this 501 protocol is more tuned for shopping on the Internet. 503 Mode of payment, credit card transactions and the actual process of 504 trading is outside the scope of this protocol and is handled by the 505 Server programs as relevant using secure socket layers. See other 506 relevant RFC's, such as RFC 1898. 508 Note that there is no passwords or authentication required to search 509 for 510 products. Everybody can browse the stores as an anonymous user. 512 If the IShop protocol is installed on a web site, Customers can easily 513 shop or setup a client program to monitor for sale prices. 515 6. REFERENCES 517 [1] Lightweight Directory Access Protocol(LDAP), RFC 1777. 519 [2] Directory and Database services - 520 http://dsm0.ds.internic.net/internic.info/proposal/ 522 [3] Multipurpose Internet Mail Extensions- RFC 2045, section 6.8 524 Base64 Content-Transfer-Encoding. 526 [4] Work In Progress - IETF Policy on Character Sets and Language 528 [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 529 1766. 531 [6] CyberCash credit card protocol version 0.8 - RFC 1898. 533 [7] Codes for the representation of currencies and funds - ISO 4217. 535 [8] External Data Representation - RFC 1014. 537 Expires: May, 1998 [Page 538 9] 540 Internet-Draft 00 Internet Shopping Protocol December 541 1997 543 7. AUTHOR'S ADDRESS 545 Ravi Reddy (editor) 546 Sharp Laboratories of America 547 5750 NW Pacific Rim Blvd 548 Camas, WA 98607 549 USA 551 Phone: 360-817-8480 552 Fax: 360-817-843609 553 Email: reddyr@sharplabs.com 555 Expires: May, 1998 [Page 556 10]