Return-Path: X-Original-To: dtn-interest@ietfa.amsl.com Delivered-To: dtn-interest@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D122B11E8095 for ; Wed, 18 Apr 2012 12:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjWI86cuQL8e for ; Wed, 18 Apr 2012 12:58:29 -0700 (PDT) Received: from kahuna.puaa.net (jwright145.dsl.frii.net [216.17.155.145]) by ietfa.amsl.com (Postfix) with ESMTP id D5D2E11E8094 for ; Wed, 18 Apr 2012 12:58:28 -0700 (PDT) Received: from kipu.bioserve.prv (bioserve.colorado.edu [128.138.158.99]) by kahuna.puaa.net (Postfix) with ESMTP id 53842E44782; Wed, 18 Apr 2012 13:58:16 -0600 (MDT) From: Jim Wright Content-Type: multipart/alternative; boundary="Apple-Mail=_B992EB4F-F1DF-426A-9E73-564C8A7E1B1B" Date: Wed, 18 Apr 2012 13:58:16 -0600 To: dtn-interest@irtf.org Message-Id: <430B6FB2-8A85-45CF-A072-C94DBF35F4CF@colorado.edu> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-PuaaConsulting-MailScanner-Information: Please contact the ISP for more information X-PuaaConsulting-MailScanner-ID: 53842E44782.AFB39 X-PuaaConsulting-MailScanner: Found to be clean X-PuaaConsulting-MailScanner-SpamScore: s X-PuaaConsulting-MailScanner-From: james.r.wright@colorado.edu Subject: [dtn-interest] Custody transfer specification in RFC5050 X-BeenThere: dtn-interest@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 19:59:57 -0000 --Apple-Mail=_B992EB4F-F1DF-426A-9E73-564C8A7E1B1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have been reading RFC5050 and specifically trying to understand the = custody transfer mechanism. In my reading of RFC5050, I see no provision = to allow for a Bundle Node to receive a bundle with the Custody Transfer = Request bit set and simply forward it on, without taking custody of the = bundle. It seems every Bundle Node MUST implement custody transfer. Is this correct? If it is not correct, and it is allowed to have a = Bundle Node that receives and forwards bundles without taking custody, = then where in RFC5050 is this specified? Thanks, Jim --=20 Jim Wright BioServe Space Technologies james.r.wright@colorado.edu 303-492-1579 --Apple-Mail=_B992EB4F-F1DF-426A-9E73-564C8A7E1B1B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I have been reading RFC5050 and specifically trying to understand the custody transfer mechanism. In my reading of RFC5050, I see no provision to allow for a Bundle Node to receive a bundle with the Custody Transfer Request bit set and simply forward it on, without taking custody of the bundle. It seems every Bundle Node MUST implement custody transfer.

Is this correct? If it is not correct, and it is allowed to have a Bundle Node that receives and forwards bundles without taking custody, then where in RFC5050 is this specified?

Thanks,
Jim



-- 
Jim Wright
BioServe Space Technologies
303-492-1579

--Apple-Mail=_B992EB4F-F1DF-426A-9E73-564C8A7E1B1B--