Subject: [dtn-interest] FW: [IANA #5080] FW: request for provisional registration of 'dtn' URI scheme name (uri-scheme)
From: "Kevin Fall" <[email-masked]>
To: "DTN" <[email-masked]>
Date: Mon, 31 Jul 2006 19:04:16 -0700
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

After quite a few months of waiting, we are finally "provisional" :P...

Cheers,
- K

> -----Original Message-----
> From: Jonathan Stewart via RT [mailto:[email-masked]]
> Sent: Monday, July 31, 2006 5:49 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [IANA #5080] FW: request for provisional registration of 'dtn'
> URI scheme name (uri-scheme)
> 
> Dear Stephen and Kevin,
> 
> We have registered the following provisional URI scheme:
> 
> dtn
> 
> Please see:
> http://www.iana.org/assignments/uri-schemes.html
> 
> Please let us know if you have any questions or if there
> are any issues with the new registration.
> 
> On behalf of the IANA,
> 
> 
> Jonathan Stewart
> Internet Assigned Numbers Authority (IANA)
> 

Date: Mon, 31 Jul 2006 15:01:02 -0700
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Custody and non-singleton endpoint nit
Sender: [email-masked]

Susan, one more thought on this topic: I think might be a very good 
thing to add a note, along the lines you propose, to the DTN 
implementer's guide.

Scott

Michael Demmer wrote:

>> My question: How is the fact that "custody acceptance by the source
>> node is required" signalled in the bundle? I don't see a flag for this.
>
> Since it's only an issue for the source node, we don't need a flag.
> This is something we discussed having as part of the application
> interface to the bundling layer, which used to be captured in that
> service interface part of the spec that we got rid of (for good reason
> I might add).
>
> But this is one of probably many bits of stored-up knowledge that
> should be captured in the dtn implementers guide document that folks
> have been mulling around.
>
> -m
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Mon, 31 Jul 2006 13:34:30 -0700
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Custody and non-singleton endpoint nit
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------090308060900020509050609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Symington, Susan F. wrote:

> Scott,
>  
> I disagree with the notion that this is just one of many things that 
> are not defined so we should just leave it the way it is. When we 
> determined that custody transfer as currently defined in the 
> specification was only applicable to bundles with singleton 
> destination endpoints, you went through the specification and inserted 
> text to the effect that "[this particular aspect of ] custody transfer 
> for a bundle whose destination is not a singleton endpoint is not 
> defined in this specification"  in at least 8 different locations, 
> that is, into all the locations in which we thought it was needed. My 
> email is just pointing out that there is one additional location in 
> which it is needed: for completeness and correctness, a similar 
> disclaimer is needed in section 4.2.
>  
> I can sympathize with your desire to be done with changes to the 
> specification, but as currently written, the specification permits a 
> source to forward a bundle whose destination is a multicast endpoint 
> for which custody transfer is requested and for which custody 
> acceptance by the source node is required with a current custodian 
> value of "dtn:none". Surely this is not something that we want to 
> allow. The text that I proposed in my email can correct this, before 
> the specification becomes and RFC, by adding a total of about 44 words 
> to it.

Susan, the point of my response was not that I was eager to be done with 
changes to the specification.  It was that this change is not needed, 
because it bears only on implementation.

The change you propose would have no impact on protocol, no impact on 
interoperability.  This is in contrast to all those other locations 
where we explicitly note the absence of definition, where we would 
otherwise have to be defining the manner in which the node must interact 
with other nodes.  The completeness and correctness of the protocol 
specification is unaffected by the presence or absence of the text you 
propose.

To try to explain this view a little further, I've inserted a couple of 
notes in-line below.

Scott

>     ------------------------------------------------------------------------
>     *From:* [email-masked]
>     [mailto:[email-masked]] *On Behalf Of *Scott
>     Burleigh
>     *Sent:* Monday, July 31, 2006 3:24 PM
>     *To:* DTNRG
>     *Subject:* Re: [dtn-interest] Custody and non-singleton endpoint nit
>
>     Symington, Susan F. wrote:
>
>>     Scott,
>>      
>>     I believe that we need to add some sort of disclaimer to section
>>     4.2 (Bundle transmission) of the Bundle Protocol that says that
>>     the conditions under which a node may commit to accepting custody
>>     of a bundle whose destination endpoint is not a singleton
>>     endpoint are not defined in the specification.
>>      
>>     It seems clear that "commit to accepting custody of the bundle"
>>     which is what is talked about in 4.2 (Bundle transmission), is
>>     different from "accept custody of the bundle", which is what is
>>     talked about in section 4.10 (Custody transfer).
>>      
>>     The Custody Transfer section makes it clear that the conditions
>>     under which a node may accept custody of a bundle whose
>>     destination is not a singleton endpoint are not defined in the
>>     spec., but the Bundle Transmission section does not make it clear
>>     that the conditions under which a node may commit to accepting
>>     custody of a bundle whose destination is not a singleton endpoint
>>     are not defined in the spec.
>
Right, because this is an implementation matter and we try to avoid 
prescribing implementation.

>>     Right now, the spec reads as though a bundle protocol agent is
>>     permitted to commit to accepting custody of a bundle that has a
>>     non-singleton endpoint.
>
Actually we don't permit or prohibit this commitment anywhere.  In one 
instance we contemplate the possibility that the user may "require" it, 
and arguably this too could be omitted; the whole concept of a bundle 
protocol agent being required to accept custody at the source is 
undefined and has no effect on the protocol.  It's a notion that at one 
time we thought was useful to expose to implementers, but no node other 
than the source node would behave any differently depending on whether 
or not that notion was implemented.

>>     But this would lead to trouble. Because next, after the bundle
>>     protocol agent has (erroneously) committed to accepting custody
>>     of a bundle with a non-singleton endpoint, the bundle protocol
>>     agent will create an outbound bundle with "dtn:none" as the
>>     current custodian, determine which endpoints to forward the
>>     bundle to, and then follow the Custody Transfer procedure defined
>>     in section 4.10. But section 4.10 says that the conditions under
>>     which a node may accept custody of a bundle whose destination is
>>     not a singleton endpoint are not defined. So when the bundle gets
>>     forwarded, it will still not have any custodian (other than
>>     "dtn:none") asserted for it.
>
No.  Instead, "So at that point the implementation fails, because it has 
committed to do something that it does not know how to do.  In general, 
we think implementations should be designed not to fail in this 
situation.  We leave that design strategy to the implementer."

>>     I don't think the bundle should have been created in the first
>>     place.  I think putting a disclaimer in section 4.2 will fix
>>     this. I propose the following be the replacement text for Step 1
>>     of section 4.2 (Bundle transmission):
>>      
>>     "Step 1: If :
>>       - custody transfer is requested for this bundle transmission,
>>       - custody acceptance by the source node is required, and
>>       - the bundle has a non-singleton destination endpoint,
>>     then the conditions under which this transmission request can be
>>     honored are not defined in this specification.
>>      
>>     If:
>>       - custody transfer is requested for this bundle transmission,
>>       - custody acceptance by the source node is required, and
>>       - the bundle has a singleton destination endpoint,
>>     then either the bundle protocol agent must commit to accepting
>>     custody of the bundle, in which case processign proceeds from
>>     Step 2, or else the request cannot be honored and all remaining
>>     steps of this procedure must be skipped."
>
>     Susan, the problem is that there are *a lot* of things that are
>     not defined in this specification, and I don't think we'd be doing
>     anybody any favors by trying to enumerate them all.  We'd just be
>     making the document a lot longer.
>
>     "Committing to accept custody of a bundle" is purely an
>     implementation matter, not least because it is dependent on
>     "custody acceptance by the source node" being "required" -- which
>     (as we have discussed on this list, June 26-27) is wholly an
>     implementation matter.
>
>     We probably already define too many things that are implementation
>     matters; I certainly don't think we should make a big deal over
>     omitting such a definition in this case.  There is no effect on
>     interoperability, and an implementer who is unable to figure out
>     that he had better not "commit" (whatever that means in the
>     context of his implementation) to doing something that the
>     specification doesn't tell him how to do is probably somebody whom
>     we should be encouraging to explore alternative career paths.
>

--------------090308060900020509050609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Symington, Susan F. wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.2912" name="GENERATOR">
  <div align="left" dir="ltr"><span class="276263819-31072006"><font
 color="#0000ff" face="Arial" size="2">Scott,</font></span></div>
  <div align="left" dir="ltr"><span class="276263819-31072006"></span>&nbsp;</div>
  <div align="left" dir="ltr"><span class="276263819-31072006"><font
 color="#0000ff" face="Arial" size="2">I disagree with the notion that
this is just one of many things that are not defined so we should just
leave it the way it is. When we determined that custody transfer as
currently defined in the specification was only applicable to bundles
with singleton destination endpoints, you went through the
specification and inserted text to the effect that "[this particular
aspect of ] custody transfer for a bundle whose destination is not a
singleton endpoint is not defined in this specification"&nbsp;&nbsp;in at least 8
different locations, that is, into all the locations in which we
thought it was needed. My email is just pointing out that there is one
additional location in which it is needed: for completeness and
correctness, a similar disclaimer is needed in section 4.2.</font></span></div>
  <div align="left" dir="ltr"><span class="276263819-31072006"></span>&nbsp;</div>
  <div align="left" dir="ltr"><font><font><font face="Arial"><font
 color="#0000ff"><font size="2"><span class="276263819-31072006">I can
sympathize with your desire to be done with changes to the
specification, but a</span><span class="276263819-31072006">s </span><span
 class="276263819-31072006">currently written, the specification
permits a source to forward a bundle whose destination is a multicast
endpoint for which custody transfer is requested and for which custody
acceptance by the source node is required with a current custodian
value of "dtn:none". Surely this is not something that we want to
allow. The text that I proposed in my email can correct this, before
the specification becomes and RFC,&nbsp;by adding a total of about 44 words
to it.</span></font></font></font></font></font></div>
</blockquote>
Susan, the point of my response was not that I was eager to be done
with changes to the specification.&nbsp; It was that this change is not
needed, because it bears only on implementation.<br>
<br>
The change you propose would have no impact on protocol, no impact on
interoperability.&nbsp; This is in contrast to all those other locations
where we explicitly note the absence of definition, where we would
otherwise have to be defining the manner in which the node must
interact with other nodes.&nbsp; The completeness and correctness of the
protocol specification is unaffected by the presence or absence of the
text you propose.<br>
<br>
To try to explain this view a little further, I've inserted a couple of
notes in-line below.<br>
<br>
Scott<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div class="OutlookMessageHeader" align="left" dir="ltr"
 lang="en-us">
    <hr tabindex="-1"> <font face="Tahoma" size="2"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] <b>On Behalf Of </b>Scott
Burleigh<br>
    <b>Sent:</b> Monday, July 31, 2006 3:24 PM<br>
    <b>To:</b> DTNRG<br>
    <b>Subject:</b> Re: [dtn-interest] Custody and non-singleton
endpoint nit<br>
    </font><br>
    </div>
Symington, Susan F. wrote:
    <blockquote
 cite="[email-masked]"
 type="cite">
      <meta content="MSHTML 6.00.2900.2912" name="GENERATOR">
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">Scott,</span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">I believe that we need to
add some sort of disclaimer to section 4.2 (Bundle transmission) of the
Bundle Protocol that says that the conditions under which a node may
commit to accepting custody of a bundle whose destination endpoint is
not a singleton endpoint are not defined in the specification. </span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">It seems clear that "commit
to accepting custody of the bundle" which is what is talked about in
4.2 (Bundle transmission), is different from "accept custody of the
bundle", which is what is talked about in section 4.10 (Custody
transfer). </span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">The Custody Transfer section
makes it clear that the conditions under which a node may accept
custody of a bundle whose destination is not a singleton endpoint are
not defined in the spec., but the Bundle Transmission section does not
make it clear that the conditions under which a node may commit to
accepting custody of a bundle whose destination is not a singleton
endpoint are not defined in the spec.</span></font></div>
    </blockquote>
  </blockquote>
</blockquote>
Right, because this is an implementation matter and we try to avoid
prescribing implementation.<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <blockquote
 cite="[email-masked]"
 type="cite">
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">Right now, the spec reads as
though a bundle protocol agent is permitted to commit to accepting
custody of a bundle that has a non-singleton endpoint.</span></font></div>
    </blockquote>
  </blockquote>
</blockquote>
Actually we don't permit or prohibit this commitment anywhere.&nbsp; In one
instance we contemplate the possibility that the user may "require" it,
and arguably this too could be omitted; the whole concept of a bundle
protocol agent being required to accept custody at the source is
undefined and has no effect on the protocol.&nbsp; It's a notion that at one
time we thought was useful to expose to implementers, but no node other
than the source node would behave any differently depending on whether
or not that notion was implemented.<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <blockquote
 cite="[email-masked]"
 type="cite">
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">But this would lead to
trouble. Because next, after the bundle protocol agent has
(erroneously) committed to accepting custody of a bundle with a
non-singleton endpoint, the bundle protocol agent will create an
outbound bundle with "dtn:none" as the current custodian, determine
which endpoints to forward the bundle to, and then follow the Custody
Transfer procedure defined in section 4.10. But section 4.10 says that
the conditions under which a&nbsp;node may accept custody of a bundle whose
destination is not a singleton endpoint are not defined. So when the
bundle gets forwarded, it will still not have any custodian (other than
"dtn:none") asserted for it.</span></font></div>
    </blockquote>
  </blockquote>
</blockquote>
No.&nbsp; Instead, "So at that point the implementation fails, because it
has committed to do something that it does not know how to do.&nbsp; In
general, we think implementations should be designed not to fail in
this situation.&nbsp; We leave that design strategy to the implementer."<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <blockquote
 cite="[email-masked]"
 type="cite">
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">I don't think the bundle
should have been created in the first place.&nbsp;&nbsp;I think putting a
disclaimer in section 4.2 will fix this. I propose the following be the
replacement text for Step 1 of section 4.2 (Bundle transmission):</span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">"Step 1: If :</span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp;&nbsp;- custody transfer is
requested for this bundle transmission,</span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp; -&nbsp;custody acceptance by
the source node is required, and</span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp; - the bundle has a
non-singleton destination endpoint, </span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">then the conditions under
which this transmission request can be honored are not defined in this
specification.</span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">If:</span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp;&nbsp;- custody transfer is
requested for this bundle transmission,</span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp; -&nbsp;custody acceptance by
the source node is required, and</span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp; - the bundle has a
singleton destination endpoint, </span></font></div>
      <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">then either the bundle
protocol agent must commit to accepting custody of the bundle, in which
case processign proceeds from Step 2, or else the request cannot be
honored and all remaining steps of this procedure must be skipped."</span></font></div>
      </span></font></div>
    </blockquote>
Susan, the problem is that there are *a lot* of things that are not
defined in this specification, and I don't think we'd be doing anybody
any favors by trying to enumerate them all.&nbsp; We'd just be making the
document a lot longer.<br>
    <br>
"Committing to accept custody of a bundle" is purely an implementation
matter, not least because it is dependent on "custody acceptance by the
source node" being "required" -- which (as we have discussed on this
list, June 26-27) is wholly an implementation matter.<br>
    <br>
We probably already define too many things that are implementation
matters; I certainly don't think we should make a big deal over
omitting such a definition in this case.&nbsp; There is no effect on
interoperability, and an implementer who is unable to figure out that
he had better not "commit" (whatever that means in the context of his
implementation) to doing something that the specification doesn't tell
him how to do is probably somebody whom we should be encouraging to
explore alternative career paths.<br>
  </blockquote>
</blockquote>
<br>
</body>
</html>

--------------090308060900020509050609--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Custody and non-singleton endpoint nit
Date: Mon, 31 Jul 2006 16:01:23 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "DTNRG" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B4DC.19BB5CC1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Scott,
=20
I disagree with the notion that this is just one of many things that
are not defined so we should just leave it the way it is. When we
determined that custody transfer as currently defined in the
specification was only applicable to bundles with singleton destination
endpoints, you went through the specification and inserted text to the
effect that "[this particular aspect of ] custody transfer for a bundle
whose destination is not a singleton endpoint is not defined in this
specification"  in at least 8 different locations, that is, into all
the locations in which we thought it was needed. My email is just
pointing out that there is one additional location in which it is
needed: for completeness and correctness, a similar disclaimer is
needed in section 4.2.
=20
I can sympathize with your desire to be done with changes to the
specification, but as currently written, the specification permits a
source to forward a bundle whose destination is a multicast endpoint
for which custody transfer is requested and for which custody
acceptance by the source node is required with a current custodian
value of "dtn:none". Surely this is not something that we want to
allow. The text that I proposed in my email can correct this, before
the specification becomes and RFC, by adding a total of about 44 words
to it.
=20
-susan
=20
=20
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
	Sent: Monday, July 31, 2006 3:24 PM
	To: DTNRG
	Subject: Re: [dtn-interest] Custody and non-singleton endpoint
nit
=09
=09
	Symington, Susan F. wrote:=20

		Scott,
		=20
		I believe that we need to add some sort of disclaimer
to section 4.2 (Bundle transmission) of the Bundle Protocol that says
that the conditions under which a node may commit to accepting custody
of a bundle whose destination endpoint is not a singleton endpoint are
not defined in the specification.=20
		=20
		It seems clear that "commit to accepting custody of the
bundle" which is what is talked about in 4.2 (Bundle transmission), is
different from "accept custody of the bundle", which is what is talked
about in section 4.10 (Custody transfer).=20
		=20
		The Custody Transfer section makes it clear that the
conditions under which a node may accept custody of a bundle whose
destination is not a singleton endpoint are not defined in the spec.,
but the Bundle Transmission section does not make it clear that the
conditions under which a node may commit to accepting custody of a
bundle whose destination is not a singleton endpoint are not defined in
the spec. =20
		=20
		Right now, the spec reads as though a bundle protocol
agent is permitted to commit to accepting custody of a bundle that has
a non-singleton endpoint. But this would lead to trouble. Because next,
after the bundle protocol agent has (erroneously) committed to
accepting custody of a bundle with a non-singleton endpoint, the bundle
protocol agent will create an outbound bundle with "dtn:none" as the
current custodian, determine which endpoints to forward the bundle to,
and then follow the Custody Transfer procedure defined in section 4.10.
But section 4.10 says that the conditions under which a node may accept
custody of a bundle whose destination is not a singleton endpoint are
not defined. So when the bundle gets forwarded, it will still not have
any custodian (other than "dtn:none") asserted for it. I don't think
the bundle should have been created in the first place.  I think
putting a disclaimer in section 4.2 will fix this. I propose the
following be the replacement text for Step 1 of section 4.2 (Bundle
transmission):
		=20
		"Step 1: If :
		  - custody transfer is requested for this bundle
transmission,
		  - custody acceptance by the source node is required,
and
		  - the bundle has a non-singleton destination
endpoint,=20
		then the conditions under which this transmission
request can be honored are not defined in this specification.
		=20
		If:
	=09
		  - custody transfer is requested for this bundle
transmission,
		  - custody acceptance by the source node is required,
and
		  - the bundle has a singleton destination endpoint,=20
		then either the bundle protocol agent must commit to
accepting custody of the bundle, in which case processign proceeds from
Step 2, or else the request cannot be honored and all remaining steps
of this procedure must be skipped."

	Susan, the problem is that there are *a lot* of things that are
not defined in this specification, and I don't think we'd be doing
anybody any favors by trying to enumerate them all.  We'd just be
making the document a lot longer.
=09
	"Committing to accept custody of a bundle" is purely an
implementation matter, not least because it is dependent on "custody
acceptance by the source node" being "required" -- which (as we have
discussed on this list, June 26-27) is wholly an implementation matter.
=09
	We probably already define too many things that are
implementation matters; I certainly don't think we should make a big
deal over omitting such a definition in this case.  There is no effect
on interoperability, and an implementer who is unable to figure out
that he had better not "commit" (whatever that means in the context of
his implementation) to doing something that the specification doesn't
tell him how to do is probably somebody whom we should be encouraging
to explore alternative career paths.
=09
	Scott
=09

------_=_NextPart_001_01C6B4DC.19BB5CC1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D276263819-31072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Scott,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D276263819-31072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D276263819-31072006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I disagree with the notion that this is just =
one of many=20
things that are not defined so we should just leave it the way it is. =
When we=20
determined that custody transfer as currently defined in the =
specification was=20
only applicable to bundles with singleton destination endpoints, you =
went=20
through the specification and inserted text to the effect that "[this =
particular=20
aspect of ] custody transfer for a bundle whose destination is not a =
singleton=20
endpoint is not defined in this specification"&nbsp;&nbsp;in at least 8=20
different locations, that is, into all the locations in which we thought =
it was=20
needed. My email is just pointing out that there is one additional =
location in=20
which it is needed: for completeness and correctness, a similar =
disclaimer is=20
needed in section 4.2.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D276263819-31072006></SPAN><FONT=20
face=3DArial><FONT color=3D#0000ff><FONT =
size=3D2></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT><FONT><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN class=3D276263819-31072006>I can sympathize with your =
desire to be=20
done with changes to the specification, but a</SPAN><SPAN=20
class=3D276263819-31072006>s </SPAN><SPAN =
class=3D276263819-31072006>currently=20
written, the specification permits a source to forward a bundle whose=20
destination is a multicast endpoint for which custody transfer is =
requested and=20
for which custody acceptance by the source node is required with a =
current=20
custodian value of "dtn:none". Surely this is not something that we want =
to=20
allow. The text that I proposed in my email can correct this, before the =

specification becomes and RFC,&nbsp;by adding a total of about 44 words =
to=20
it.</SPAN></FONT></FONT></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT><FONT><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN=20
class=3D276263819-31072006></SPAN></FONT></FONT></FONT></FONT></FONT>&nbs=
p;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT><FONT><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
size=3D2><SPAN=20
class=3D276263819-31072006>-susan</SPAN></FONT></FONT></FONT></FONT></FON=
T></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D276263819-31072006></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D276263819-31072006></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D276263819-31072006></SPAN></FONT></FONT></FONT><FONT =
face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of =
</B>Scott=20
  Burleigh<BR><B>Sent:</B> Monday, July 31, 2006 3:24 PM<BR><B>To:</B>=20
  DTNRG<BR><B>Subject:</B> Re: [dtn-interest] Custody and non-singleton =
endpoint=20
  nit<BR></FONT><BR></DIV>
  <DIV></DIV>Symington, Susan F. wrote:=20
  <BLOCKQUOTE =
cite=[email-masked]=20
  type=3D"cite">
    <META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>Scott,</SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>I believe that we need to add some sort =
of=20
    disclaimer to section 4.2 (Bundle transmission) of the Bundle =
Protocol that=20
    says that the conditions under which a node may commit to accepting =
custody=20
    of a bundle whose destination endpoint is not a singleton endpoint =
are not=20
    defined in the specification. </SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>It seems clear that "commit to accepting =
custody of=20
    the bundle" which is what is talked about in 4.2 (Bundle =
transmission), is=20
    different from "accept custody of the bundle", which is what is =
talked about=20
    in section 4.10 (Custody transfer). </SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>The Custody Transfer section makes it =
clear that=20
    the conditions under which a node may accept custody of a bundle =
whose=20
    destination is not a singleton endpoint are not defined in the =
spec., but=20
    the Bundle Transmission section does not make it clear that the =
conditions=20
    under which a node may commit to accepting custody of a bundle whose =

    destination is not a singleton endpoint are not defined in the =
spec.&nbsp;=20
    </SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2><SPAN class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>Right now, the spec reads as though a =
bundle=20
    protocol agent is permitted to commit to accepting custody of a =
bundle that=20
    has a non-singleton endpoint. But this would lead to trouble. =
Because next,=20
    after the bundle protocol agent has (erroneously) committed to =
accepting=20
    custody of a bundle with a non-singleton endpoint, the bundle =
protocol agent=20
    will create an outbound bundle with "dtn:none" as the current =
custodian,=20
    determine which endpoints to forward the bundle to, and then follow =
the=20
    Custody Transfer procedure defined in section 4.10. But section 4.10 =
says=20
    that the conditions under which a&nbsp;node may accept custody of a =
bundle=20
    whose destination is not a singleton endpoint are not defined. So =
when the=20
    bundle gets forwarded, it will still not have any custodian (other =
than=20
    "dtn:none") asserted for it. I don't think the bundle should have =
been=20
    created in the first place.&nbsp;&nbsp;I think putting a disclaimer =
in=20
    section 4.2 will fix this. I propose the following be the =
replacement text=20
    for Step 1 of section 4.2 (Bundle transmission):</SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>"Step 1: If :</SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>&nbsp;&nbsp;- custody transfer is =
requested for=20
    this bundle transmission,</SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>&nbsp; -&nbsp;custody acceptance by the =
source node=20
    is required, and</SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>&nbsp; - the bundle has a non-singleton =
destination=20
    endpoint, </SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>then the conditions under which this =
transmission=20
    request can be honored are not defined in this=20
    specification.</SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>If:</SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>&nbsp;&nbsp;- custody transfer is =
requested for=20
    this bundle transmission,</SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>&nbsp; -&nbsp;custody acceptance by the =
source node=20
    is required, and</SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>&nbsp; - the bundle has a singleton =
destination=20
    endpoint, </SPAN></FONT></DIV>
    <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
    class=3D654142817-31072006>then either the bundle protocol agent =
must commit=20
    to accepting custody of the bundle, in which case processign =
proceeds from=20
    Step 2, or else the request cannot be honored and all remaining =
steps of=20
    this procedure must be=20
  skipped."</SPAN></FONT></DIV></SPAN></FONT></DIV></BLOCKQUOTE>Susan, =
the=20
  problem is that there are *a lot* of things that are not defined in =
this=20
  specification, and I don't think we'd be doing anybody any favors by =
trying to=20
  enumerate them all.&nbsp; We'd just be making the document a lot=20
  longer.<BR><BR>"Committing to accept custody of a bundle" is purely an =

  implementation matter, not least because it is dependent on "custody=20
  acceptance by the source node" being "required" -- which (as we have =
discussed=20
  on this list, June 26-27) is wholly an implementation =
matter.<BR><BR>We=20
  probably already define too many things that are implementation =
matters; I=20
  certainly don't think we should make a big deal over omitting such a=20
  definition in this case.&nbsp; There is no effect on interoperability, =
and an=20
  implementer who is unable to figure out that he had better not =
"commit"=20
  (whatever that means in the context of his implementation) to doing =
something=20
  that the specification doesn't tell him how to do is probably somebody =
whom we=20
  should be encouraging to explore alternative career=20
paths.<BR><BR>Scott<BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6B4DC.19BB5CC1--

Date: Mon, 31 Jul 2006 12:23:31 -0700
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] Custody and non-singleton endpoint nit
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------090707050205010007020609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Symington, Susan F. wrote:

> Scott,
>  
> I believe that we need to add some sort of disclaimer to section 4.2 
> (Bundle transmission) of the Bundle Protocol that says that the 
> conditions under which a node may commit to accepting custody of a 
> bundle whose destination endpoint is not a singleton endpoint are not 
> defined in the specification.
>  
> It seems clear that "commit to accepting custody of the bundle" which 
> is what is talked about in 4.2 (Bundle transmission), is different 
> from "accept custody of the bundle", which is what is talked about in 
> section 4.10 (Custody transfer).
>  
> The Custody Transfer section makes it clear that the conditions under 
> which a node may accept custody of a bundle whose destination is not a 
> singleton endpoint are not defined in the spec., but the Bundle 
> Transmission section does not make it clear that the conditions under 
> which a node may commit to accepting custody of a bundle whose 
> destination is not a singleton endpoint are not defined in the spec. 
>  
> Right now, the spec reads as though a bundle protocol agent is 
> permitted to commit to accepting custody of a bundle that has a 
> non-singleton endpoint. But this would lead to trouble. Because next, 
> after the bundle protocol agent has (erroneously) committed to 
> accepting custody of a bundle with a non-singleton endpoint, the 
> bundle protocol agent will create an outbound bundle with "dtn:none" 
> as the current custodian, determine which endpoints to forward the 
> bundle to, and then follow the Custody Transfer procedure defined in 
> section 4.10. But section 4.10 says that the conditions under which 
> a node may accept custody of a bundle whose destination is not a 
> singleton endpoint are not defined. So when the bundle gets forwarded, 
> it will still not have any custodian (other than "dtn:none") asserted 
> for it. I don't think the bundle should have been created in the first 
> place.  I think putting a disclaimer in section 4.2 will fix this. I 
> propose the following be the replacement text for Step 1 of section 
> 4.2 (Bundle transmission):
>  
> "Step 1: If :
>   - custody transfer is requested for this bundle transmission,
>   - custody acceptance by the source node is required, and
>   - the bundle has a non-singleton destination endpoint,
> then the conditions under which this transmission request can be 
> honored are not defined in this specification.
>  
> If:
>   - custody transfer is requested for this bundle transmission,
>   - custody acceptance by the source node is required, and
>   - the bundle has a singleton destination endpoint,
> then either the bundle protocol agent must commit to accepting custody 
> of the bundle, in which case processign proceeds from Step 2, or else 
> the request cannot be honored and all remaining steps of this 
> procedure must be skipped."

Susan, the problem is that there are *a lot* of things that are not 
defined in this specification, and I don't think we'd be doing anybody 
any favors by trying to enumerate them all.  We'd just be making the 
document a lot longer.

"Committing to accept custody of a bundle" is purely an implementation 
matter, not least because it is dependent on "custody acceptance by the 
source node" being "required" -- which (as we have discussed on this 
list, June 26-27) is wholly an implementation matter.

We probably already define too many things that are implementation 
matters; I certainly don't think we should make a big deal over omitting 
such a definition in this case.  There is no effect on interoperability, 
and an implementer who is unable to figure out that he had better not 
"commit" (whatever that means in the context of his implementation) to 
doing something that the specification doesn't tell him how to do is 
probably somebody whom we should be encouraging to explore alternative 
career paths.

Scott

--------------090707050205010007020609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Symington, Susan F. wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.2912" name="GENERATOR">
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">Scott,</span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">I believe that we need to
add some sort of disclaimer to section 4.2 (Bundle transmission) of the
Bundle Protocol that says that the conditions under which a node may
commit to accepting custody of a bundle whose destination endpoint is
not a singleton endpoint are not defined in the specification. </span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">It seems clear that "commit
to accepting custody of the bundle" which is what is talked about in
4.2 (Bundle transmission), is different from "accept custody of the
bundle", which is what is talked about in section 4.10 (Custody
transfer). </span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">The Custody Transfer section
makes it clear that the conditions under which a node may accept
custody of a bundle whose destination is not a singleton endpoint are
not defined in the spec., but the Bundle Transmission section does not
make it clear that the conditions under which a node may commit to
accepting custody of a bundle whose destination is not a singleton
endpoint are not defined in the spec.&nbsp; </span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font><font
 color="#0000ff" face="Arial" size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">Right now, the spec reads as
though a bundle protocol agent is permitted to commit to accepting
custody of a bundle that has a non-singleton endpoint. But this would
lead to trouble. Because next, after the bundle protocol agent has
(erroneously) committed to accepting custody of a bundle with a
non-singleton endpoint, the bundle protocol agent will create an
outbound bundle with "dtn:none" as the current custodian, determine
which endpoints to forward the bundle to, and then follow the Custody
Transfer procedure defined in section 4.10. But section 4.10 says that
the conditions under which a&nbsp;node may accept custody of a bundle whose
destination is not a singleton endpoint are not defined. So when the
bundle gets forwarded, it will still not have any custodian (other than
"dtn:none") asserted for it. I don't think the bundle should have been
created in the first place.&nbsp;&nbsp;I think putting a disclaimer in section
4.2 will fix this. I propose the following be the replacement text for
Step 1 of section 4.2 (Bundle transmission):</span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">"Step 1: If :</span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp;&nbsp;- custody transfer is
requested for this bundle transmission,</span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp; -&nbsp;custody acceptance by
the source node is required, and</span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp; - the bundle has a
non-singleton destination endpoint, </span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">then the conditions under
which this transmission request can be honored are not defined in this
specification.</span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006"></span></font>&nbsp;</div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">If:</span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp;&nbsp;- custody transfer is
requested for this bundle transmission,</span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp; -&nbsp;custody acceptance by
the source node is required, and</span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">&nbsp; - the bundle has a
singleton destination endpoint, </span></font></div>
  <div align="left" dir="ltr"><font color="#0000ff" face="Arial"
 size="2"><span class="654142817-31072006">then either the bundle
protocol agent must commit to accepting custody of the bundle, in which
case processign proceeds from Step 2, or else the request cannot be
honored and all remaining steps of this procedure must be skipped."</span></font></div>
  </span></font></div>
</blockquote>
Susan, the problem is that there are *a lot* of things that are not
defined in this specification, and I don't think we'd be doing anybody
any favors by trying to enumerate them all.&nbsp; We'd just be making the
document a lot longer.<br>
<br>
"Committing to accept custody of a bundle" is purely an implementation
matter, not least because it is dependent on "custody acceptance by the
source node" being "required" -- which (as we have discussed on this
list, June 26-27) is wholly an implementation matter.<br>
<br>
We probably already define too many things that are implementation
matters; I certainly don't think we should make a big deal over
omitting such a definition in this case.&nbsp; There is no effect on
interoperability, and an implementer who is unable to figure out that
he had better not "commit" (whatever that means in the context of his
implementation) to doing something that the specification doesn't tell
him how to do is probably somebody whom we should be encouraging to
explore alternative career paths.<br>
<br>
Scott<br>
</body>
</html>

--------------090707050205010007020609--

Content-class: urn:content-classes:message
Date: Mon, 31 Jul 2006 14:17:45 -0400
From: "Symington, Susan F." <[email-masked]>
To: "Scott Burleigh" <[email-masked]>
Cc: "DTNRG" <[email-masked]>
Subject: [dtn-interest] Custody and non-singleton endpoint nit
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6B4CD.9FD9B069
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Scott,
=20
I believe that we need to add some sort of disclaimer to section 4.2
(Bundle transmission) of the Bundle Protocol that says that the
conditions under which a node may commit to accepting custody of a
bundle whose destination endpoint is not a singleton endpoint are not
defined in the specification.=20
=20
It seems clear that "commit to accepting custody of the bundle" which
is what is talked about in 4.2 (Bundle transmission), is different from
"accept custody of the bundle", which is what is talked about in
section 4.10 (Custody transfer).=20
=20
The Custody Transfer section makes it clear that the conditions under
which a node may accept custody of a bundle whose destination is not a
singleton endpoint are not defined in the spec., but the Bundle
Transmission section does not make it clear that the conditions under
which a node may commit to accepting custody of a bundle whose
destination is not a singleton endpoint are not defined in the spec. =20
=20
Right now, the spec reads as though a bundle protocol agent is
permitted to commit to accepting custody of a bundle that has a
non-singleton endpoint. But this would lead to trouble. Because next,
after the bundle protocol agent has (erroneously) committed to
accepting custody of a bundle with a non-singleton endpoint, the bundle
protocol agent will create an outbound bundle with "dtn:none" as the
current custodian, determine which endpoints to forward the bundle to,
and then follow the Custody Transfer procedure defined in section 4.10.
But section 4.10 says that the conditions under which a node may accept
custody of a bundle whose destination is not a singleton endpoint are
not defined. So when the bundle gets forwarded, it will still not have
any custodian (other than "dtn:none") asserted for it. I don't think
the bundle should have been created in the first place.  I think
putting a disclaimer in section 4.2 will fix this. I propose the
following be the replacement text for Step 1 of section 4.2 (Bundle
transmission):
=20
"Step 1: If :
  - custody transfer is requested for this bundle transmission,
  - custody acceptance by the source node is required, and
  - the bundle has a non-singleton destination endpoint,=20
then the conditions under which this transmission request can be
honored are not defined in this specification.
=20
If:
  - custody transfer is requested for this bundle transmission,
  - custody acceptance by the source node is required, and
  - the bundle has a singleton destination endpoint,=20
then either the bundle protocol agent must commit to accepting custody
of the bundle, in which case processign proceeds from Step 2, or else
the request cannot be honored and all remaining steps of this procedure
must be skipped."
=20
-susan
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

------_=_NextPart_001_01C6B4CD.9FD9B069
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>Scott,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>I believe that we need to add some sort of =
disclaimer=20
to section 4.2 (Bundle transmission) of the Bundle Protocol that says =
that the=20
conditions under which a node may commit to accepting custody of a =
bundle whose=20
destination endpoint is not a singleton endpoint are not defined in the=20
specification. </SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>It seems clear that "commit to accepting =
custody of the=20
bundle" which is what is talked about in 4.2 (Bundle transmission), is =
different=20
from "accept custody of the bundle", which is what is talked about in =
section=20
4.10 (Custody transfer). </SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>The Custody Transfer section makes it clear =
that the=20
conditions under which a node may accept custody of a bundle whose =
destination=20
is not a singleton endpoint are not defined in the spec., but the Bundle =

Transmission section does not make it clear that the conditions under =
which a=20
node may commit to accepting custody of a bundle whose destination is =
not a=20
singleton endpoint are not defined in the spec.&nbsp; =
</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><SPAN class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>Right now, the spec reads as though a bundle =
protocol=20
agent is permitted to commit to accepting custody of a bundle that has a =

non-singleton endpoint. But this would lead to trouble. Because next, =
after the=20
bundle protocol agent has (erroneously) committed to accepting custody =
of a=20
bundle with a non-singleton endpoint, the bundle protocol agent will =
create an=20
outbound bundle with "dtn:none" as the current custodian, determine =
which=20
endpoints to forward the bundle to, and then follow the Custody Transfer =

procedure defined in section 4.10. But section 4.10 says that the =
conditions=20
under which a&nbsp;node may accept custody of a bundle whose destination =
is not=20
a singleton endpoint are not defined. So when the bundle gets forwarded, =
it will=20
still not have any custodian (other than "dtn:none") asserted for it. I =
don't=20
think the bundle should have been created in the first =
place.&nbsp;&nbsp;I think=20
putting a disclaimer in section 4.2 will fix this. I propose the =
following be=20
the replacement text for Step 1 of section 4.2 (Bundle=20
transmission):</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>"Step 1: If :</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>&nbsp;&nbsp;- custody transfer is requested =
for this=20
bundle transmission,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>&nbsp; -&nbsp;custody acceptance by the =
source node is=20
required, and</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>&nbsp; - the bundle has a non-singleton =
destination=20
endpoint, </SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>then the conditions under which this =
transmission=20
request can be honored are not defined in this=20
specification.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>If:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>&nbsp;&nbsp;- custody transfer is requested =
for this=20
bundle transmission,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>&nbsp; -&nbsp;custody acceptance by the =
source node is=20
required, and</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>&nbsp; - the bundle has a singleton =
destination=20
endpoint, </SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D654142817-31072006>then either the bundle protocol agent must =
commit to=20
accepting custody of the bundle, in which case processign proceeds from =
Step 2,=20
or else the request cannot be honored and all remaining steps of this =
procedure=20
must be skipped."</SPAN></FONT></DIV></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D654142817-31072006><FONT face=3DArial color=3D#0000ff =

size=3D2>-susan</FONT></SPAN></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C6B4CD.9FD9B069--

Date: Fri, 28 Jul 2006 13:06:25 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Regarding bundle header type field
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060801050103020209090009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Wesley Eddy wrote:

>On Fri, Jul 28, 2006 at 12:28:52PM -0700, Scott Burleigh wrote:
>  
>
>>I agree with the sense of RFC 3692, but that raises another issue: RFC 
>>3692 is specifically oriented toward IANA-based procedures, and we don't 
>>identify BP block numbers as an IANA consideration.  Should we?
>>    
>>
>Since BP is currently only targeted at Experimental, I don't think it's
>worth the trouble of having IANA manage these numbers, but I think the
>guidance in that RFC generally applies here.  Specifically, that is:
>designate and use a small experimental range for when things are still
>experimental, and _move them_ into assigned range if/when they become
>more standard, reaping the experimental number rather than reducing
>the experimental space by redesignating the number.
>  
>
>>I think BP block numbers are more like the latter than the former, so I 
>>think they are not an IANA consideration; therefore RFC 3692 doesn't 
>>strictly apply.
>>    
>>
>I fully agree with you.  I'm refering to the general wisdom for managing
>experimental vs. well-defined space rather than the specific application
>of this proceedure with regards to IANA.
>  
>
Okay, we completely agree.

--------------060801050103020209090009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Wesley Eddy wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">On Fri, Jul 28, 2006 at 12:28:52PM -0700, Scott Burleigh wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I agree with the sense of RFC 3692, but that raises another issue: RFC 
3692 is specifically oriented toward IANA-based procedures, and we don't 
identify BP block numbers as an IANA consideration.  Should we?
    </pre>
  </blockquote>
  <pre wrap=""><!---->Since BP is currently only targeted at Experimental, I don't think it's
worth the trouble of having IANA manage these numbers, but I think the
guidance in that RFC generally applies here.  Specifically, that is:
designate and use a small experimental range for when things are still
experimental, and _move them_ into assigned range if/when they become
more standard, reaping the experimental number rather than reducing
the experimental space by redesignating the number.
  </pre>
  <blockquote type="cite">
    <pre wrap="">I think BP block numbers are more like the latter than the former, so I 
think they are not an IANA consideration; therefore RFC 3692 doesn't 
strictly apply.
    </pre>
  </blockquote>
  <pre wrap=""><!---->I fully agree with you.  I'm refering to the general wisdom for managing
experimental vs. well-defined space rather than the specific application
of this proceedure with regards to IANA.
  </pre>
</blockquote>
Okay, we completely agree.<br>
</body>
</html>

--------------060801050103020209090009--

Date: Fri, 28 Jul 2006 15:54:54 -0400
From: Wesley Eddy <[email-masked]>
To: Scott Burleigh <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Regarding bundle header type field
Reply-To: [email-masked]
Sender: [email-masked]

On Fri, Jul 28, 2006 at 12:28:52PM -0700, Scott Burleigh wrote:
> I agree with the sense of RFC 3692, but that raises another issue: RFC 
> 3692 is specifically oriented toward IANA-based procedures, and we don't 
> identify BP block numbers as an IANA consideration.  Should we?

Since BP is currently only targeted at Experimental, I don't think it's
worth the trouble of having IANA manage these numbers, but I think the
guidance in that RFC generally applies here.  Specifically, that is:
designate and use a small experimental range for when things are still
experimental, and _move them_ into assigned range if/when they become
more standard, reaping the experimental number rather than reducing
the experimental space by redesignating the number.

> I think BP block numbers are more like the latter than the former, so I 
> think they are not an IANA consideration; therefore RFC 3692 doesn't 
> strictly apply.

I fully agree with you.  I'm refering to the general wisdom for managing
experimental vs. well-defined space rather than the specific application
of this proceedure with regards to IANA.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Fri, 28 Jul 2006 12:28:52 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Regarding bundle header type field
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------080807000907040207050805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Wesley Eddy wrote:

>On Fri, Jul 28, 2006 at 02:40:32PM -0400, Jayram Deshpande wrote:
>  
>
>>>Hi Jay,
>>>
>>>I'm not sure about a range for experimentation, but codes 2, 3 and 4 are
>>>already reserved for security headers. That's described in the security
>>>specs, not the base documents.
>>>
>>>I would expect that values beyond, say, sixteen  are probably OK.
>>>      
>>>
>>May be we should update the bundle spec to reflect this experimental range.
>>It would be better if the reserved range is alsoupdated everytime a new 
>>extension header is standardized.
>>    
>>
>I think we need to consult RFC 3692 on this, and utilize the agreed upon BCP.
>
I agree with the sense of RFC 3692, but that raises another issue: RFC 
3692 is specifically oriented toward IANA-based procedures, and we don't 
identify BP block numbers as an IANA consideration.  Should we?

I'm skeptical.  IANA and RFC 3692 seem to me to be about standardizing 
the potential values of PDU fields that are variable content (such as 
protocol number in the IP packet, which in theory plays no part in the 
operation of IP itself) rather than those that are static and structural 
(such as commands, reply codes, and block descriptor codes in FTP, which 
must be identified in the protocol spec because protocol procedure 
descriptions reference them).

I think BP block numbers are more like the latter than the former, so I 
think they are not an IANA consideration; therefore RFC 3692 doesn't 
strictly apply.

Scott

--------------080807000907040207050805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Wesley Eddy wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">On Fri, Jul 28, 2006 at 02:40:32PM -0400, Jayram Deshpande wrote:
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">Hi Jay,

I'm not sure about a range for experimentation, but codes 2, 3 and 4 are
already reserved for security headers. That's described in the security
specs, not the base documents.

I would expect that values beyond, say, sixteen  are probably OK.
      </pre>
    </blockquote>
    <pre wrap="">May be we should update the bundle spec to reflect this experimental range.
It would be better if the reserved range is alsoupdated everytime a new 
extension header is standardized.
    </pre>
  </blockquote>
  <pre wrap=""><!---->I think we need to consult RFC 3692 on this, and utilize the agreed upon BCP.</pre>
</blockquote>
I agree with the sense of RFC 3692, but that raises another issue: RFC
3692 is specifically oriented toward IANA-based procedures, and we
don't identify BP block numbers as an IANA consideration.&nbsp; Should we?<br>
<br>
I'm skeptical.&nbsp; IANA and RFC 3692 seem to me to be about standardizing
the potential values of PDU fields that are variable content (such as
protocol number in the IP packet, which in theory plays no part in the
operation of IP itself) rather than those that are static and
structural (such as commands, reply codes, and block descriptor codes
in FTP, which must be identified in the protocol spec because protocol
procedure descriptions reference them).<br>
<br>
I think BP block numbers are more like the latter than the former, so I
think they are not an IANA consideration; therefore RFC 3692 doesn't
strictly apply.<br>
<br>
Scott<br>
</body>
</html>

--------------080807000907040207050805--

Date: Fri, 28 Jul 2006 15:00:17 -0400
From: Wesley Eddy <[email-masked]>
To: Jayram Deshpande <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-interest] Regarding bundle header type field
Reply-To: [email-masked]
Sender: [email-masked]

--OROCMA9jn6tkzFBc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 28, 2006 at 02:40:32PM -0400, Jayram Deshpande wrote:
> >=20
> > Hi Jay,
> >=20
> > I'm not sure about a range for experimentation, but codes 2, 3 and 4 are
> > already reserved for security headers. That's described in the security
> > specs, not the base documents.
> >=20
> > I would expect that values beyond, say, sixteen  are probably OK.
> >=20
>=20
> May be we should update the bundle spec to reflect this experimental rang=
e.
> It would be better if the reserved range is alsoupdated everytime a new=
=20
> extension header is standardized.
>=20

I think we need to consult RFC 3692 on this, and utilize the agreed upon BC=
P.

--=20
Wesley M. Eddy
Verizon Federal Network Systems

--OROCMA9jn6tkzFBc
Content-Type: application/pgp-signature
Content-Disposition: inline

--OROCMA9jn6tkzFBc--

Date: Fri, 28 Jul 2006 11:53:26 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Regarding bundle header type field
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------000600060909050404030007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jayram Deshpande wrote:

>On Fri, Jul 28, 2006 at 07:10:28AM -0400, Peter Lovell wrote:
>  
>
>>>Hi folks,
>>>
>>>I was just wondering if we have a value range defined for the
>>>bundle header type field that we can use for experimentation purposes only.
>>>As I understand, the  bundle header block type code 1 is for bundle payload
>>>and all other values of the header block type code are reserved for future 
>>>use [1].
>>>
>>>Defining a range will be useful for those of us who are trying out new
>>>ideas prior to going for a full-fledged process of 'type field value'
>>>standardization.
>>>
>>>thanx.
>>>Jay
>>>
>>>[1] bundle protocol spec - 5 
>>>
>>>
>>>      
>>>
>>Hi Jay,
>>
>>I'm not sure about a range for experimentation, but codes 2, 3 and 4 are
>>already reserved for security headers. That's described in the security
>>specs, not the base documents.
>>
>>I would expect that values beyond, say, sixteen  are probably OK.
>>
>>Regards.....Peter
>>
>>    
>>
>
>May be we should update the bundle spec to reflect this experimental range.
>  
>
I agree, provided we've got consensus.

>It would be better if the reserved range is alsoupdated everytime a new 
>extension header is standardized.
>  
>
I would prefer that we not go through so much thrashing of the bundle 
protocol spec.  I would propose that designers of new BP blocks use 
symbolic block numbers in their documents and code, initially using 
numbers drawn from the experimental range as the values of those symbols 
and later receiving numbers from the "reserved" range when the blocks 
move toward standardization (just as has been done with the bundle 
security protocol blocks).  Then we don't have to change either the 
experimental range (the numbers are reused) or the reserved range 
(reserved numbers are permanently allocated to new blocks at the time 
the specs for those blocks become DTNRG-consensus RFCs, and that 
allocation is documented in those RFCs).

Scott

--------------000600060909050404030007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jayram Deshpande wrote:
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">On Fri, Jul 28, 2006 at 07:10:28AM -0400, Peter Lovell wrote:
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">Hi folks,

I was just wondering if we have a value range defined for the
bundle header type field that we can use for experimentation purposes only.
As I understand, the  bundle header block type code 1 is for bundle payload
and all other values of the header block type code are reserved for future 
use [1].

Defining a range will be useful for those of us who are trying out new
ideas prior to going for a full-fledged process of 'type field value'
standardization.

thanx.
Jay

[1] bundle protocol spec - 5 

      </pre>
    </blockquote>
    <pre wrap="">Hi Jay,

I'm not sure about a range for experimentation, but codes 2, 3 and 4 are
already reserved for security headers. That's described in the security
specs, not the base documents.

I would expect that values beyond, say, sixteen  are probably OK.

Regards.....Peter

    </pre>
  </blockquote>
  <pre wrap=""><!---->
May be we should update the bundle spec to reflect this experimental range.
  </pre>
</blockquote>
I agree, provided we've got consensus.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">It would be better if the reserved range is alsoupdated everytime a new 
extension header is standardized.
  </pre>
</blockquote>
I would prefer that we not go through so much thrashing of the bundle
protocol spec.&nbsp; I would propose that designers of new BP blocks use
symbolic block numbers in their documents and code, initially using
numbers drawn from the experimental range as the values of those
symbols and later receiving numbers from the "reserved" range when the
blocks move toward standardization (just as has been done with the
bundle security protocol blocks).&nbsp; Then we don't have to change either
the experimental range (the numbers are reused) or the reserved range
(reserved numbers are permanently allocated to new blocks at the time
the specs for those blocks become DTNRG-consensus RFCs, and that
allocation is documented in those RFCs).<br>
<br>
Scott<br>
</body>
</html>

--------------000600060909050404030007--

Date: Fri, 28 Jul 2006 14:40:32 -0400
From: Jayram Deshpande <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Regarding bundle header type field
Reply-To: [email-masked]
Sender: [email-masked]

--ZPt4rx8FFjLCG7dd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 28, 2006 at 07:10:28AM -0400, Peter Lovell wrote:
> >Hi folks,
> >
> >I was just wondering if we have a value range defined for the
> >bundle header type field that we can use for experimentation purposes on=
ly.
> >As I understand, the  bundle header block type code 1 is for bundle payl=
oad
> >and all other values of the header block type code are reserved for futu=
re=20
> >use [1].
> >
> >Defining a range will be useful for those of us who are trying out new
> >ideas prior to going for a full-fledged process of 'type field value'
> >standardization.
> >
> >thanx.
> >Jay
> >
> >[1] bundle protocol spec - 5=20
> >
> >=20
>=20
> Hi Jay,
>=20
> I'm not sure about a range for experimentation, but codes 2, 3 and 4 are
> already reserved for security headers. That's described in the security
> specs, not the base documents.
>=20
> I would expect that values beyond, say, sixteen  are probably OK.
>=20
> Regards.....Peter
>=20

May be we should update the bundle spec to reflect this experimental range.
It would be better if the reserved range is alsoupdated everytime a new=20
extension header is standardized.

Jay

=20

--ZPt4rx8FFjLCG7dd
Content-Type: application/pgp-signature
Content-Disposition: inline

--ZPt4rx8FFjLCG7dd--

From: Hans Kruse <[email-masked]>
Subject: Re: [dtn-interest] Regarding bundle header type field
Date: Fri, 28 Jul 2006 12:54:08 -0400
To: [email-masked]
Sender: [email-masked]

--Apple-Mail-7--295210270
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

I agree, especially with the use of the upper range of the number space.

On Jul 28, 2006, at 12:10, Scott Burleigh wrote:

> Peter Lovell wrote:
>
>>> Hi folks,
>>>
>>> I was just wondering if we have a value range defined for the
>>> bundle header type field that we can use for experimentation  
>>> purposes only.
>>> As I understand, the  bundle header block type code 1 is for  
>>> bundle payload
>>> and all other values of the header block type code are reserved  
>>> for future use [1].
>>>
>>> Defining a range will be useful for those of us who are trying  
>>> out new
>>> ideas prior to going for a full-fledged process of 'type field  
>>> value'
>>> standardization.
>>>
> I think this is a good idea.  We just had the same sort of  
> conversation for LTP and ended up setting aside 1/4 of the  
> extension tag number space for private / experimental use.   
> Allocating BP block type numbers 192 through 255 to private /  
> experimental use would be the equivalent.
>
> Scott
>
>> Hi Jay,
>>
>> I'm not sure about a range for experimentation, but codes 2, 3 and  
>> 4 are
>> already reserved for security headers. That's described in the  
>> security
>> specs, not the base documents.
>>
>> I would expect that values beyond, say, sixteen  are probably OK.
>>
>> Regards.....Peter
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
>>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer  
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

--Apple-Mail-7--295210270
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">I agree, especially with the use =
of the upper range of the number space.<DIV><BR><DIV><DIV>On Jul 28, =
2006, at 12:10, Scott Burleigh wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Peter Lovell wrote:</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV> <BLOCKQUOTE type=3D"cite"><BLOCKQUOTE =
type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Hi folks,</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I was =
just wondering if we have a value range defined for the</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">bundle header type field that we can use for =
experimentation purposes only.</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">As I =
understand, the<SPAN class=3D"Apple-converted-space">=A0 </SPAN>bundle =
header block type code 1 is for bundle payload</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">and all other values of the header block type code =
are reserved for future use [1].</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Defining a range will be useful =
for those of us who are trying out new</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">ideas =
prior to going for a full-fledged process of 'type field =
value'</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">standardization.</DIV><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px"><SPAN =
class=3D"Apple-converted-space">=A0 =A0</SPAN><BR =
class=3D"khtml-block-placeholder"></P> </BLOCKQUOTE></BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I think this is a good idea.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>We just had the same sort of =
conversation for LTP and ended up setting aside 1/4 of the extension tag =
number space for private / experimental use.<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>Allocating BP block type =
numbers 192 through 255 to private / experimental use would be the =
equivalent.</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">Scott</DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><BR></DIV> <BLOCKQUOTE type=3D"cite"><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Hi =
Jay,</DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">I'm not sure about a range for experimentation, but =
codes 2, 3 and 4 are</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">already reserved for =
security headers. That's described in the security</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">specs, not the base documents.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I would =
expect that values beyond, say, sixteen<SPAN =
class=3D"Apple-converted-space">=A0 </SPAN>are probably OK.</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Regards.....Peter</DIV><DIV style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; =
"><BR></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">dtn-interest mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked].=
org</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mai=
lman.dtnrg.org/mailman/listinfo/dtn-interest</A></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px; min-height: 14.0px"><SPAN =
class=3D"Apple-converted-space">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></P> </BLOCKQUOTE><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><BR></DIV><DIV style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">dtn-interest mailing list</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"mailto:[email-masked]">[email-masked].=
org</A></DIV><DIV style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mai=
lman.dtnrg.org/mailman/listinfo/dtn-interest</A></DIV> =
</BLOCKQUOTE></DIV><BR><DIV> <SPAN class=3D"Apple-style-span" =
style=3D"border-collapse: separate; border-spacing: 0px 0px; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; text-align: auto; =
-khtml-text-decorations-in-effect: none; text-indent: 0px; =
-apple-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Hans Kruse, Professor</FONT></P><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">J. Warren McClure School of =
Information and Telecommunication Systems</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">Adjunct Associate Professor of =
Electrical Engineering and Computer Science</FONT></P><P style=3D"margin: =
0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" =
style=3D"font: 12.0px Helvetica">292 Lindley Hall, Ohio University, =
Athens, OH, 45701</FONT></P><P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">740-593-4891 voice, 740-593-4889 fax</FONT></P><BR =
class=3D"Apple-interchange-newline"></SPAN> =
</DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-7--295210270--

Cc: [email-masked]
From: Michael Demmer <[email-masked]>
Subject: Re: [dtn-interest] Regarding bundle header type field
Date: Fri, 28 Jul 2006 09:24:33 -0700
To: Scott Burleigh <[email-masked]>
Sender: [email-masked]

On Jul 28, 2006, at 9:10 AM, Scott Burleigh wrote:

> Peter Lovell wrote:
>
>>> Hi folks,
>>>
>>> I was just wondering if we have a value range defined for the
>>> bundle header type field that we can use for experimentation  
>>> purposes only.
>>> As I understand, the  bundle header block type code 1 is for  
>>> bundle payload
>>> and all other values of the header block type code are reserved  
>>> for future use [1].
>>>
>>> Defining a range will be useful for those of us who are trying  
>>> out new
>>> ideas prior to going for a full-fledged process of 'type field  
>>> value'
>>> standardization.
>>>
> I think this is a good idea.  We just had the same sort of  
> conversation for LTP and ended up setting aside 1/4 of the  
> extension tag number space for private / experimental use.   
> Allocating BP block type numbers 192 through 255 to private /  
> experimental use would be the equivalent.

I'd second (third?) that proposal.

-m

Date: Fri, 28 Jul 2006 09:10:02 -0700
From: Scott Burleigh <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] Regarding bundle header type field
Sender: [email-masked]

Peter Lovell wrote:

>>Hi folks,
>>
>>I was just wondering if we have a value range defined for the
>>bundle header type field that we can use for experimentation purposes only.
>>As I understand, the  bundle header block type code 1 is for bundle payload
>>and all other values of the header block type code are reserved for future 
>>use [1].
>>
>>Defining a range will be useful for those of us who are trying out new
>>ideas prior to going for a full-fledged process of 'type field value'
>>standardization.
>>    
>>
I think this is a good idea.  We just had the same sort of conversation 
for LTP and ended up setting aside 1/4 of the extension tag number space 
for private / experimental use.  Allocating BP block type numbers 192 
through 255 to private / experimental use would be the equivalent.

Scott

>Hi Jay,
>
>I'm not sure about a range for experimentation, but codes 2, 3 and 4 are
>already reserved for security headers. That's described in the security
>specs, not the base documents.
>
>I would expect that values beyond, say, sixteen  are probably OK.
>
>Regards.....Peter
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>  
>

From: "Peter Lovell" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [dtn-interest] Regarding bundle header type field
Date: Fri, 28 Jul 2006 07:10:28 -0400
Sender: [email-masked]

>Hi folks,
>
>I was just wondering if we have a value range defined for the
>bundle header type field that we can use for experimentation purposes only.
>As I understand, the  bundle header block type code 1 is for bundle payload
>and all other values of the header block type code are reserved for future 
>use [1].
>
>Defining a range will be useful for those of us who are trying out new
>ideas prior to going for a full-fledged process of 'type field value'
>standardization.
>
>thanx.
>Jay
>
>[1] bundle protocol spec - 5 
>
> 

Hi Jay,

I'm not sure about a range for experimentation, but codes 2, 3 and 4 are
already reserved for security headers. That's described in the security
specs, not the base documents.

I would expect that values beyond, say, sixteen  are probably OK.

Regards.....Peter

Date: Fri, 28 Jul 2006 02:46:53 -0400
From: Jayram Deshpande <[email-masked]>
To: [email-masked]
Reply-To: [email-masked]
Subject: [dtn-interest] Regarding bundle header type field
Sender: [email-masked]

--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi folks,

I was just wondering if we have a value range defined for the
bundle header type field that we can use for experimentation purposes only.
As I understand, the  bundle header block type code 1 is for bundle payload
and all other values of the header block type code are reserved for future=
=20
use [1].

Defining a range will be useful for those of us who are trying out new
ideas prior to going for a full-fledged process of 'type field value'
standardization.

thanx.
Jay

[1] bundle protocol spec - 5=20

=20

--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature
Content-Disposition: inline

--LZvS9be/3tNcYl/X--

Date: Wed, 26 Jul 2006 21:12:26 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: DTN <[email-masked]>
Subject: [dtn-interest] CBC or counter mode?
Sender: [email-masked]

In the current bundle security spec [1] we define a confidentiality
ciphersuite (CH-RSA-AES-PAYLOAD-PSH) that uses AES's cipher-block
chaining (CBC) mode of operation.

CBC mode means that all ciphertext bits depend on all previous
ciphertext bits, so you if you loose some bits from the middle
of the bundle payload then you can no longer decrypt the bits
that follow.

There are other modes of operation generally termed "counter mode"
which do allow for decryption even if some bits get lost. Generally
these modes are a little trickier since its easier to misuse them
and do the wrong security thing, but that's a problem we can solve.
Counter mode is also better from the p-o-v of parallel processing
but I don't think that matters as much here as the improved support
for fragmentation.

So, should we change from CBC to counter mode? I think we should
and that we should decide that now, since there are folks writing
code and it'd be better if we get this done before they release
their stuff. (There is an alternative which is to define two
ciphersuites but that makes the security document longer which is
a bad thing.)

Stephen.

[1] 
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-security-01.txt

Date: Mon, 24 Jul 2006 23:42:58 +0100
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [Fwd: Re: [dtn-interest] Activity?]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------000005020300040002090401
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Oops - forgot to cc the list. I guess someone else might
want to find out where to start...

S.

--------------000005020300040002090401
Content-Type: message/rfc822;
 name="Re: [dtn-interest] Activity?"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: [dtn-interest] Activity?"

Message-ID: <[email-masked]>
Date: Mon, 24 Jul 2006 23:22:40 +0100
From: Stephen Farrell <[email-masked]>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Hylton Conacher(ZR1HPC)" <[email-masked]>
Subject: Re: [dtn-interest] Activity?
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Suggest you take a look at the dtnrg site [1] and/or the current
set of internet drafts [2]. That's probably the best way to get
up to speed, but you can also look to the archives of this list
as well [3].

Cheers,
Stephen.

[1] http://www.dtnrg.org/
[2] 
https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_job_owner=0&search_group_acronym=&search_status_id=&search_cur_state=&sub_state_id=6&search_filename=dtnrg&search_rfcnumber=&search_area_acronym=&search_button=SEARCH
[3] http://mailman.dtnrg.org/pipermail/dtn-interest/

Hylton Conacher(ZR1HPC) wrote:
> So what's happening on this group as I am set to see a single mesage?
> 
> Hylton

--------------000005020300040002090401--

Date: Mon, 24 Jul 2006 10:44:56 +0200
From: "Hylton Conacher(ZR1HPC)" <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Activity?
Sender: [email-masked]

So what's happening on this group as I am set to see a single mesage?

Hylton
-- 
========================================================================
Currently using SuSE 9.2 Professional with KDE and Mozilla 1.7.2
Linux user # 229959 at http://counter.li.org
========================================================================

Reply-To: <[email-masked]>
From: "Kevin Fall" <[email-masked]>
To: "DTN" <[email-masked]>
Date: Fri, 14 Jul 2006 09:06:36 -0700
Organization: Intel Research Berkeley
Subject: [dtn-interest] thinking about compression & sigcomp
Sender: [email-masked]

This got mucked up the first time.   Here's is a re-send:

- K

> -----Original Message-----
> From: Kevin Fall [mailto:[email-masked]]
> Sent: Thursday, July 13, 2006 7:14 AM
> To: DTN
> Subject: thinking about compression & sigcomp
> 
> 
> 
> I thought some folks might be interested in this and maybe haven't looked
> at it before.
> 
> 
> 
> IETF RFC 3320 (from 2003) specifies a method to help with 'signaling
> compression'.  What is sort of interesting here is that this RFC really
> specifies a form of active networks.  In particular, it specifies a
> virtual machine to which you can send code.  Although designed for
> decompression, it includes a more general VM.  Two relatively new RFCs
> (4464, 4465) describe a 'users's guide' and 'torture tests'.
> 
> 
> 
> The model is based upon the idea that the compression can be accomplished
> however you want, but the decompression is accomplished by executing the
> VM code you include in your packets or messages.  What might be nice (for
> us) is that the remote end doesn't have to know the structure of the upper
> layer protocols {because you just include the decompressor code}.
> 
> 
> 
> -          K
> 
> 
> 
> 
> 
> Related Links:
> 
> 
> 
> http://www.opensigcomp.org/
> 
> http://rfc.net/rfc3320.html
> 
> http://rfc.net/rfc4464.html
> 
> http://rfc.net/rfc4465.html
> 
> http://www.99-bottles-of-beer.net/language-assembler-(udvm)-49.html
> 
> 

Date: Thu, 06 Jul 2006 09:26:30 +0300
From: Joerg Ott <[email-masked]>
To: DTN <[email-masked]>
CC: Omar Mukhtar <[email-masked]>, Joerg Ott <[email-masked]>
Subject: [dtn-interest] DTN for Symbian implementation available
Sender: [email-masked]

Hi,

we have just released DASM v0.1, a DTN implementation for
Symbian phones (tested with Nokia Communicators 9300i
and 9500).  This is an independent implementation tailored
to the particular needs of the Symbian OS.

Our implementation is based upon draft-ietf-dtnrg-bundle-spec-04
and the draft TCP convergence layer spec available from the
code Wiki of the reference implementation.  It also supports
a Bluetooth convergence layer.

DASM is interoperable with the DTN reference implementation
2.2.0 (we have also tested a snapshot from the cvs repository
from 29 June 2006), and we have tested with cygwin, the
Nokia Internet tablet 770, and (in an earlier version) also
with Linux.

We will supply some additional simple demo tools soon (for
email-style but DTN-based messaging to and from the Symbian
phone, e.g., to send and receive images), but for now we
wanted to get this out for people to play with (in case of
a rainy summer :-).  In any case, by adding (and accepting)
some Mail headers, you can use dtnsend (and dtnrecv) for
interaction with the phone application.

DASM has an API for routing and local applications so that
it can be integrated with other work hopefully (easily).
Also, further convergence layers can be added.

At the bottom of http://www.netlab.tkk.fi/~jo/dtn/index.html
you will find some further information from a recent demo
as well as a pointer to the source code (published under GPL).

Omar & Joerg

Reply-To: <[email-masked]>
From: "Eiko Yoneki" <[email-masked]>
To: <[email-masked]>
Date: Wed, 5 Jul 2006 09:49:22 +0100
Importance: Normal
Subject: [dtn-interest] [DL July 10th RDDS 2006] Workshop on Reliability in Decentralized Distributed Systems
Sender: [email-masked]

(Apologies if you receive multiple copies of this message)  

**** Final Submission Deadline is July 10, 2006 **** 
--------------------------------------------------------------------------

International Workshop on Reliability in Decentralized Distributed Systems
(RDDS 2006) 
http://www.cs.rmit.edu.au/fedconf/index.html?page=rdds2006cfp

In conjunction with ON THE MOVE FEDERATED CONFERENCES 2006
(OTM'06-ODBASE/DOA/CoopIS/GADA) http://www.cs.rmit.edu.au/fedconf 

Montpellier, France, Oct 29 - Nov 3, 2006
Proceedings will be published by Springer Verlag

--------------------------------------------------------------------------

WORKSHOP THEME 

Middleware has become a popular technology for building distributed systems
from tiny sensor networks to large scale peer-to-peer (P2P) networks.
Support such as asynchronous and multipoint communication is well suited for
constructing reactive distributed computing applications over wired and
wireless networks environments. While middleware infrastructures exhibit
attractive features from an application development perspective (e.g.,
portability, interoperability, adaptability etc.), they are often lacking in
robustness and reliability. Distributed systems become increasingly large
and complex, thereby compounding many reliability problems that necessitate
different strategies and solutions.

For example, in the inherently distributed nature of P2P networks, the most
common solution to reliability is to take advantage of redundancy. The same
task can be initially assigned to multiple peers. In file sharing
applications, data can be replicated across many peers. In messaging
applications, messages can be simultaneously sent along multiple paths.
Redundancy may not be appropriate, however, in resource-constrained
environments such as wireless ad hoc networks where more lightweight
alternatives are needed. Some systems even rely on autonomic management
technologies inspired by nature and biological organisms to cope with the
challenges of scale, complexity, heterogeneity and unpredictability. In any
case, the system model (e.g., communication, failures) and application
requirements are key factors in the design of reliably mechanisms.

Among different aspects of reliability issues, this workshop focuses on
reliability in decentralized distributed systems. While decentralized
architectures are gaining adoption is most application domains, there is
still some reluctance in deploying them in systems with high dependability
requirements. This has led, over the past few years, to several academic and
industrial research efforts aimed at correcting this deficiency. For the
most part, these research efforts have been independent of each other, and
have often focused on specific pieces of the dependability puzzle. Our aim,
in this Workshop, is to bring researchers and practitioners together, to
further our insights on reliable decentralized architectures and to
investigate collectively the challenges that remain.

GOAL

The purpose of the RDDS 2006 workshop on Reliability in Distributed
Decentralized Systems is to bring together researchers from diverse
communities who are interested in building dependable reliable distributed
systems in decentralized form, to explore ways of making today's middleware
technologies more robust, and to discuss and exchange experimental or
theoretical results, novel design, work-in-progress, experience, case study,
and trend-setting ideas. We seek contributions from researchers of all
backgrounds, in particular peer-to-peer systems, messaging, ad hoc
communication, middleware and distributed systems, and autonomic management
systems.

TOPICS OF INTEREST 

The Workshop solicits contributions on topics related to, but not limited
to, the following: 

-  Reliable communication, architectures and algorithms 
-  Lessons learned in building/using dependable middleware: what works, what
doesn't? 
-  Integrating dependable embedded and enterprise middleware systems 
-  Trade-offs in adding other "-ilities" (survivability, adaptability,
scalability, availability, mobility, security, real-time, etc.) to reliable
middleware infrastructures 
-  Integration of dependability into formal distributed object models 
-  Shaping/enhancing standards for reliable middleware 
-  Evaluating dependability for middleware applications 
-  Limitations of existing fault tolerance technologies in the context of
middleware applications 
-  Metrics, benchmarks and performance studies in evaluating reliability for
middleware applications 
-  Combining different dependability strategies, e.g., replication with
transactions 
-  Self-healing, self-protecting systems 
-  Autonomic system management 
-  Reliability measurement, modelling and evaluation 
-  Tools for design and evaluation of reliable systems 
-  Application-specific reliable system (e.g.embedded systems, Web,
databases) 
-  Enabling technologies for self-managing systems and networks 
-  Economic, biological and social models used for autonomic communications 
-  Timeliness and availability in support of reliability 
-  QoS for reliable systems

IMPORTANT DATES

Deadline for paper submission June 30th, 2006
Notification of acceptance August 10th, 2006
Deadline for camera-ready papers August 20th, 2006

SUBMISSION GUIDELINES

All submitted papers will be carefully evaluated based on originality,
significance, technical soundness, and clarity of expression. All
submissions must be in English. Submissions should be in PDF format and must
not exceed 10 pages in the final camera-ready format for regular papers and
4 pages for position papers. 

Authors instructions can be found at: 
http://www.springer.de/comp/lncs/authors.html 

The paper submission site is located at: 
http://www.cs.rmit.edu.au/fedconf/rdds/2006/papers 

Accepted workshop contributions will be published by Springer-Verlag as LNCS
(Lecture Notes in Computer Science) as a part of the workshop proceedings of
the 2006 International On The Move Federated Conferences (OTM). Registering
to the OTM conference and RDDS workshop is a prerequisite for the paper to
be published. 

CONTACT PEOPLE:

Eiko Yoneki
Computer Laboratory
University of Cambridge 
United Kingdom
Email: [email-masked]

Pascal Felber
Dependable and Distributed Computing Group
Université de Neuchâtel 
Institut d'informatique
Switzerland
Email: [email-masked]

PROGRAM COMMITTEE

- Licia Capra (University College London, UK) 
- Mariano Cilia (Darmstadt University of Technology, Germany) 
- Vittorio Cortellessa (Universita' de L'Aquila, Italy) 
- Simon Courtenage (University of Westminster, UK) 
- Patrick Eugster (Purdue University, USA) 
- Ludger Fiege (Siemens Research, Germany) 
- Maria Gradinariu (IRISA/INRIA-CNRS, France)
- Eli Katsiri (Imperial College London, UK) 
- Michael Kounavis (Intel Research, USA) 
- Marco Mamei (Università di Modena, Italy) 
- Jon Munson (IBM T J Watson Research Center, USA) 
- Maziar Nekovee (BT Research, UK) 
- Andrea Passarella (IIT-CNR, Italy) 
- Peter Pietzuch (Harvard University, USA) 
- Matthieu Roy (LAAS-CNRS, France)
- François Taïani (Lancaster University, UK) 
- Niki Trigoni (Birkbeck University London, UK) 
- Einar Vollset (Cornell University, USA)