From beepwg-admin@lists.beepcore.org Wed Nov 5 01:31:54 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25768 for ; Wed, 5 Nov 2003 01:31:52 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id hA56UKOA011526; Tue, 4 Nov 2003 22:30:25 -0800 (PST) Received: from wetware.com (wetware.wetware.com [199.108.16.1]) by qawoor.dbc.mtview.ca.us (8.12.10/8.12.9) with ESMTP id hA56TUOA011501 for ; Tue, 4 Nov 2003 22:29:30 -0800 (PST) Received: from [208.177.152.18] (helo=[10.0.1.2]) by wetware.com with esmtp (Exim 4.20) id 1AHHA7-0000In-Ta; Tue, 04 Nov 2003 22:29:04 -0800 In-Reply-To: <28915501A44DBA4587FE1019D675F98307C71F@grfint.intern.adiscon.com> References: <28915501A44DBA4587FE1019D675F98307C71F@grfint.intern.adiscon.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <598A3A54-0F59-11D8-A525-000393BA7EBA@wetware.com> Content-Transfer-Encoding: 7bit Cc: From: james woodyatt Subject: Re: [BEEPwg] RFC3080 MSG/RPY Window To: "Rainer Gerhards" X-Mailer: Apple Mail (2.606) Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 4 Nov 2003 22:29:03 -0800 Content-Transfer-Encoding: 7bit On 16 Sep 2003, at 02:02, Rainer Gerhards wrote: > > [...] There are two advancing "message ids" in BEEP. One is the seqno, > the other is the msgno. [...] There is no requirement that 'msgno' numbers advance in any sequential order. In fact, if an implementation never pipelines multiple MSG entities before receiving the corresponding RPY/ERR/ANS/NUL response frames, then the 'msgno' field in the MSG header could always be zero. The 'msgno' field is only required for sanity-checking the correlation between MSG entities and their response entities. It *may* be useful for other things, therefore: it's my opinion that generalized implementations of RFC 3080 should allow applications to control the value of the 'msgno' field in the header. Also, keep in mind that the 'Content-Id' entity header field may be used in messages to uniquely and globally identify messages on a persistent basis. -- j h woodyatt _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg