idnits 2.17.1 draft-ietf-calsch-rtreq-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-24) 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 6 months document validity. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == 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 an Abstract section. ** The document seems to lack an Introduction section. ** 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.) ** There are 3 instances 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 60: '... the receiving system MUST not contain...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 2.2. iCalendar Profiles It is assumed that specific profiles have been defined for iCalendar so that each iCalendar object completely describes how a receiving calendar system should interpret the received object. The mechanism used to deliver the iCalendar object to the receiving system MUST not contain data that will affect the interpretation of the iCalendar object. == 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 (March 1997) is 9902 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) No issues found here. Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Ganguly 2 Internet Draft: Real-time protocol requirements CSI 3 March 1997 4 Expires 5-Oct-1997 6 Real-time Protocol Requirements 8 Status of this memo 10 This document is an Internet Draft. Internet Drafts are 11 working documents of the Internet Engineering Task Force 12 (IETF), its Areas, and its Working Groups. Note that other 13 groups may also distribute working documents as Internet 14 Drafts. 16 Internet Drafts are draft documents valid for a maximum of 17 six months. Internet Drafts may be updated, replaced, or 18 obsoleted by other documents at any time. It is not 19 appropriate to use Internet Drafts as reference material or 20 to cite them other than as a ``working draft'' or ``work in 21 progress``. 23 To learn the current status of any Internet-Draft, please 24 check the 1id-abstracts.txt listing contained in the 25 Internet-Drafts Shadow Directories on ds.internic.net, 26 nic.nordu.net, ftp.isi.edu, or munnari.oz.au. 28 A revised version of this draft document will be submitted 29 to the IESG as a Proposed Standard for the Internet 30 Community. Discussion and suggestions for improvement are 31 requested. This document will expire six months after 32 publication. Distribution of this draft is unlimited. 34 1. Abstract: 35 The purpose of this document is to create a framework for 36 selecting the appropriate solution for a real-time protocol 37 designed to allow calendaring and scheduling systems from 38 different vendors to interoperate. To that end, it 39 describes the assumptions about the context in which this 40 protocol will operate, and the requirements that the 41 protocol must meet. 43 These requirements are not intended to apply to a companion 44 protocol which will use E-mail based transport to achieve 45 interoperability. The E-mail based protocol, which is the 46 subject of a different document, will not make any 47 assumptions about transport latency. 49 2. Assumptions: 51 2.1. iCalendar 52 It is assumed that events will be represented as iCalendar 53 objects encoded using MIME. 55 2.2. iCalendar Profiles 56 It is assumed that specific profiles have been defined for 57 iCalendar so that each iCalendar object completely describes 58 how a receiving calendar system should interpret the 59 received object. The mechanism used to deliver the 60 iCalendar object to the receiving system MUST not contain 61 data that will affect the interpretation of the iCalendar 62 object. 64 2.3. iCalendar Attendee identification 65 It is assumed that iCalendar attendees are identified as 66 RFC822 addresses. Further, for an individual we assume that 67 this address is their e-mail address. 69 3. Requirements: 71 3.1. Bounded latency 72 The protocol must be capable of returning a response to the 73 requester (client) within a definite limited time (<60 74 seconds ???). A mechanism needs to exist to inform the 75 client that a well formed request has been received within a 76 limited time. This will be necessary to support exchanges 77 where processing time on the receiver would exceed the 78 definite limited time. 80 3.2. Simple 81 The protocol should be simple to understand, debug and to 82 implement on a variety of devices capable of connection to a 83 IP internetwork. 85 3.3. Leverages existing, widely deployed Internet 86 technologies 87 Wherever possible, the protocol should reuse existing, 88 widely deployed Internet technologies or popular conventions 89 rather than invent a new technology unnecessarily. 91 3.4. Efficient for the particular task 92 The protocol should efficiently handle the task it is 93 designed to handle, establishing interoperability between 94 calendaring and scheduling systems. As such, generality is 95 not a goal for this protocol. 97 3.5. Scaleable 98 The protocol should be designed to handle communication from 99 any Internet node to any other Internet node, that is, it 100 should support an unbounded number of users and servers. 102 The protocol should support an unbounded number of servers 103 per domain. A domain is a part of the address as defined in 104 RFC822. 106 The protocol should be designed to handle a large number of 107 calendars (i.e. users, resources, etc.) per server. 109 3.6. Secure 110 The protocol should be designed to ensure that the 111 communicating nodes are who they are supposed to be. 113 The protocol should be designed to enable private 114 communication between nodes. 116 The protocol should be designed to work well with and be 117 deployed in conjunction with existing firewall technology. 119 3.7. Server address resolution 120 The protocol should define the mechanism that the client 121 will use to locate the appropriate servers corresponding to 122 the attendee addresses contained in the iCalendar object 123 that is submitted for transport. 125 3.8. Easy deployment and administration 126 The protocol should be easily deployed within the existing 127 Internet infrastructure. That is, it should not require 128 substantial new technology or administrative overhead or 129 cause incompatibilities with existing technology. In fact, 130 it should fit well into the existing infrastructure. 132 4. Acknowledgments: 133 Thanks to the following people for helpful comments on an 134 earlier draft: Einar Stefferud, Derik Stenerson, Frank 135 Dawson and Steve Hanna. 137 5. Author's Address: 138 Anik Ganguly 139 Campbell Services, Inc. 140 21700 Northwestern Highway, 10th Floor 141 Southfield, MI 48075 USA 143 Email: anik@ontime.com 145 Document expires: 5-Oct-1997