Re: [dtn] [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26: (with DISCUSS and COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi,

My current proposal is to simply note that this specification of the DTN URI has
a restricted syntax compared to RFC 5050 that was not as clear on what syntax
was allowed. And this is simply based on that there now exists an ABNF that
describes the syntax. 

I was mistaken about the general URI syntax, and thus have no issue with
continuing as currently specified. 

Cheers

Magnus



On Fri, 2020-10-30 at 14:07 -0700, Benjamin Kaduk wrote:
> Hi Scott,
> 
> On Fri, Oct 30, 2020 at 04:56:39PM +0000, Burleigh, Scott C (US 312B) wrote:
> > Ben, would Magnus's suggestion address your Discuss?
> 
> To be honest, I'm not sure whether Magnus's latest suggestion is to both
> change the ABNF and add discussion of the potential backwards compatibility
> issues, or to leave the ABNF as it is in the -27 and add such discussion.
> 
> The ABNF in the -27 addresses the issue that I was unsure about.  Though,
> given that there apparently remains some uncertainty, I am adding the ART
> ADs to the "to:" line on this message in an attempt to have some authority
> (pun intended) present.  (Very brief summary for Barry and Murray: the URI
> "dtn:none" has been in use since at least RFC 5050 and is explicitly used
> in this document, but prior to the -27 the dtn-uri ABNF construction in
> this document did not allow for a "dtn:none" URI value.  Magnus seems to be
> proposing that this would more properly be expressed as "dtn://none" to
> match the typical URI structure, while acknowledging that there would be
> backward compatibility issues with making such a change.)
> 
> > And is your other Discuss now addressed?
> 
> Yes, Ran's text looks good.  I will go update my ballot position shortly.
> 
> Thanks,
> 
> Ben
> 
> > 
> > -----Original Message-----
> > From: Magnus Westerlund <[e-mail]> 
> > Sent: Friday, October 30, 2020 8:27 AM
> > To: [e-mail]; scott.c.burleigh=[e-mail]; 
> > [e-mail]; [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]; 
> > [e-mail]
> > Subject: Re: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26: 
> > (with DISCUSS and COMMENT)
> > 
> > Hi Scott and Ben,
> > 
> > 
> > On Wed, 2020-10-28 at 13:43 +0000, Burleigh, Scott C (US 312B) wrote:
> > > Magnus, I don't understand why this is a problem.  Isn't "dtn:none" simply
> > > a
> > > URI whose scheme is "dtn" and whose hier-part is the path-rootless
> > > "none"?  The leading characters "//" are prohibited when the path contains
> > > no
> > > authority, as is the case here.
> > 
> > Sorry, didn't read the complete ABNF so I the missed the path aspect of it.
> > 
> > I think I understand what Ben discuss is about. So RFC 5050 are explicitly
> > talking about "dtn:none" as the null endpoint ID. However, the earlier
> > versions
> > of the definition for the updated URI ABNF syntax in BPbis did not include
> > that
> > aspect. I will note that RFC 5050 do not contain any ABNF for the "dtn"
> > scheme
> > what I can find.
> > 
> > So thus "dtn:none" is within expected usage, but maybe what really is
> > missing is
> > a discussion of the potential backwards compatibility issues due to the
> > tightening of the URI scheme syntax. Maybe Section 4.1.5.1.1 needs to have a
> > paragraph on what has been changed from the provisional registration. 
> > 
> > Cheers
> > 
> > Magnus 
> > 
> > 
> > 
> > > 
> > > Scott
> > > 
> > > -----Original Message-----
> > > From: Magnus Westerlund <magnus.westerlund=[e-mail]> 
> > > Sent: Wednesday, October 28, 2020 1:10 AM
> > > To: Burleigh, Scott C (US 312B) <[e-mail]>; 
> > > [e-mail]
> > > ; [e-mail]
> > > Cc: [e-mail]; [e-mail]; [e-mail]; 
> > > [e-mail]
> > > Subject: Re: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-
> > > 26:
> > > (with DISCUSS and COMMENT)
> > > 
> > > On Wed, 2020-10-28 at 01:40 +0000, Burleigh, Scott C (US 312B) wrote:
> > > > Responses in-line below.
> > > > 
> > > > Scott
> > > > 
> > > > -----Original Message-----
> > > > From: Benjamin Kaduk via Datatracker <[e-mail]> 
> > > > Sent: Friday, October 23, 2020 6:24 PM
> > > > To: The IESG <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]; [e-mail];
> > > > Fred
> > > > Templin <[e-mail]>; [e-mail]
> > > > Subject: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26:
> > > > (with
> > > > DISCUSS and COMMENT)
> > > > 
> > > > Benjamin Kaduk has entered the following ballot position for
> > > > draft-ietf-dtn-bpbis-26: Discuss
> > > > 
> > > > ----------------------------------------------------------------------
> > > > DISCUSS:
> > > > ----------------------------------------------------------------------
> > > 
> > > ...
> > > 
> > > > (11) The ABNF for the "dtn" URI scheme does not seem to allow for a URI
> > > > of "dtn:none".  We may need to consult the ART ADs to determine how
> > > > problematic this is, as this is a bit outside my area of expertise.
> > > > 
> > > > 	Good point.  Revisions are noted in 4.1.5.1.1 of draft -27.
> > > 
> > > I think it is a no-go. This change makes it incompatible with the ABNF for
> > > URIs
> > > in general (RFC3986). I think a potential fix is to reserve the "none" as
> > > a
> > > real
> > > node name changing the dtn-uri to say:
> > > 
> > > OLD:
> > > dtn-uri = "dtn:" ("none"/dtn-hier-part)
> > > 
> > > NEW: 
> > > 
> > > dtn-uri = "dtn:" ("//none" / dtn-hier-part)
> > > 
> > > Or somethign equivalent. I think it could be reserved in the node-name
> > > rule
> > > also
> > > and that may look clearer. 
> > > 
> > > Although this is a compatibility impacting change the parser part would be
> > > fine
> > > and none changed compared to before. So it is only BPv7 compatible
> > > implementations that would do the special interpreation of none. 
> > > 
> > > 
> > > Cheers
> > > 
> > > Magnus