idnits 2.17.1 draft-ietf-lemonade-notification-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 288. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-ietf-lemonade-notification-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-lemonade-notification-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-lemonade-notification-', but the file name used is 'draft-ietf-lemonade-notification-protocol-00' == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([NOTIFICATIONS], [LEMONADEPROFILEBIS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == 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 (June 2006) is 6525 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) == Missing Reference: 'RFC2119' is mentioned on line 55, but not defined == Missing Reference: 'RFC3501' is mentioned on line 64, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Unused Reference: 'LEMONADEPROFILE' is defined on line 224, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 243, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 245, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 247, but no explicit reference was found in the text -- No information found for draft-ietf-lemonade-profile-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LEMONADEPROFILE' -- No information found for draft-ietf-lemonade-profile-bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LEMONADEPROFILEBIS' -- No information found for draft-maes-lemonade-notifications-server-to-client-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NOTIFICATIONS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PARLAYXMULTIMEDIA' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 8 errors (**), 1 flaw (~~), 12 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Lemonade 2 Internet Draft: Lemonade Notifications and S. H. Maes 3 Filters 4 Document: draft-ietf-lemonade-notification- 5 protocol-00.txt 6 Expires: December 2006 June 2006 8 Lemonade Notification protocol 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 30, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document introduces a notification protocol as a specified 42 particular case of the notification mechanisms used by the Lemonade 43 profile [LEMONADEPROFILEBIS] in [NOTIFICATIONS]. 45 This document also discusses the use of Lemonade notifications to 46 implement server to server notifications. 48 Conventions used in this document 49 In examples, "C:" and "S:" indicate lines sent by the client and 50 server respectively. 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 An implementation is not compliant if it fails to satisfy one or more 57 of the MUST or REQUIRED level requirements for the protocol(s) it 58 implements. An implementation that satisfies all the MUST or REQUIRED 59 level and all the SHOULD level requirements for a protocol is said to 60 be "unconditionally compliant" to that protocol; one that satisfies 61 all the MUST level requirements but not all the SHOULD level 62 requirements is said to be "conditionally compliant." When 63 describing the general syntax, some definitions are omitted as they 64 are defined in [RFC3501]. 66 Table of Contents 68 Status of this Memo...............................................1 69 Copyright Notice..................................................1 70 Abstract..........................................................1 71 Conventions used in this document.................................1 72 Table of Contents.................................................2 73 1. Introduction...................................................2 74 2. Usage Model....................................................3 75 2.1. Notification protocol in Lemonade Profile Bis.............3 76 2.2. Notification protocol for generic server to server 77 notifications..................................................4 78 3. Notification protocol..........................................5 79 3.1. Protocol details and guidelines...........................6 80 Security Considerations...........................................6 81 References........................................................6 82 Future Work.......................................................6 83 Acknowledgments...................................................6 84 Authors Addresses.................................................7 85 Intellectual Property Statement...................................7 86 Disclaimer of Validity............................................7 87 Copyright Statement...............................................8 88 Acknowledgement...................................................8 90 1. 91 Introduction 93 This draft provides a notification protocols for [NOTIFICATIONS] and 94 the Lemonade profile. 96 2. 97 Usage Model 99 2.1. 100 Notification protocol in Lemonade Profile Bis 102 The target logical architectures involving the LEMONADE Profile and 103 notifications are discussed in [LEMONADEPROFILEBIS]. 105 Figure 1 illustrates how notification and filtering can be introduced 106 in the context of LEMONADE profile bis. 108 +--------------+_____________ 109 | | 110 +---------| Notification | 111 | | Mechanism | 112 | +----------^---+ 113 |Notif. | 114 |Protocol -------\ +|-+_ 115 | ______| +---\>|NF|----+____ 116 | | | +--+ | +-----+ _____ 117 __v__| IMAP +--+_LEMONADE +---+__ESMTP +--+ | 118 +-----+<-------->|VF| IMAP |DF |<--------|AF| MTA | 119 | MUA |\ ME-2a +--+ Store +-^-+ +--+_____| 120 |_____| \ +-------------+ | +-----+ 121 +-----+--\---------------|-------+ 122 \ |URLAUTH 123 \SUBMIT | 124 \ +----v-----+_____ 125 \ | | +-----+ _____ 126 \ | LEMONADE | ESMTP | | 127 ---->| Submit |--------------->| MTA | 128 ME-2b | Server | |_____| 129 |__________| +-----+ 130 +----------+ 132 Figure 1: Filtering mechanism defined in LEMONADE Profile bis 133 architecture. 135 In Figure 1, the notification protocol MAY be used between NF in the 136 Lemonade IMAP Store and a compliant Notification mechanism. 138 Note that in general [LEMONADEPROFILEBIS] does not mandate the use of 139 the present notification protocol. It is also possible that NF 140 interacts with the notification mechanisms via protocols specific to 141 each of the notification mechanisms. The present draft solely 142 provides a generic protocol to do so that the notification mechanism 143 MAY support. 145 2.2. 146 Notification protocol for generic server to server 147 notifications 149 As discussed in [NOTIFICATIONS], with server to server notifications, 150 a messaging system (e.g. email server, voice mail system, etc.) 151 submits alerts, which describe potential notification events, 152 regarding an end user mailbox status change (e.g. new message has 153 arrived, mailbox is full, etc.). 155 These alerts are sent to a notification mechanisms, which may, in 156 turn, generate an end user alert notification. 158 The present notification protocol MAY be used as a generic way to 159 interface with each server to server notification mechanisms. 161 As described in {NOTIFICATIONS], it is also possible to interact with 162 the notification mechanisms via protocols specific to each of the 163 notification mechanism. The present draft solely provides a generic 164 protocol to do so that the notification mechanism MAY support. 166 The figure 2 depicts the server to server notification scope: 168 +--------+ +--------+ 169 New | | | SMS | 170 Message | Email | \ |Gateway | 171 -------> |Server 1| \ _ | | 172 +--------+ \ /| +--------+ 173 ^ \ / 174 | \ / ^ 175 | \ +--------------+ / | +--------+ 176 +--------+ | _|+-------------|+ / | | MWI | 177 Read | Voice | | || |/ | |Gateway | 178 Message | Mail |-------->| Notification |------->| | 179 -------> | Server | | ^ _ +| Mechanisms |\ ^ | +--------+ 180 +--------+ | | /| +--------------- \ | | 181 | |/ \ \| | 182 | / ^ \ ^ \ | 183 |/| | \ | |\| 184 +--------+ / | | \ | | \ +--------+ 185 Mailbox | | /| | | \| | |\ | Wap | 186 Full | Email |/ | | | ^ \ | |_|| Push | 187 -------> |Server 2| | | | | |\| | |Gateway | 188 +--------+ | | | | | \ | +--------+ 189 | | | | | |\| 190 | | | | | | \ 191 | | | | | | |\ 192 | | | | | | |_|+--------+ 193 | | | | | | | | IM | 194 | | | | | | | |Gateway | 195 | | | | | | | | | 196 | | | | | | | +--------+ 197 | | | | | | | 198 Server to OTHER 199 Server PROTOCOLS 200 Notifications 202 Figure 2: Scope of server to server notifications 204 3. 205 Notification protocol 206 The notification protocol MUST follow the [PARLAYXMULTIMEDIA] 207 protocol (over SOAP). 209 3.1. 210 Protocol details and guidelines 212