Re: Revision of RFC 7302

[Ted Hardie <[e-mail]>]

On Mon, May 2, 2016 at 2:40 PM, Pierre-Anthony Lemieux <[e-mail]>
wrote:

> Hi Ted,
>
> > You can include an appendix with a list of the changes.  That's
> non-normative,
> > but it would likely be consulted by anyone who wanted to simply check on
> the
> > relationship between the two.
>
> This sounds like a promising approach since the reader is left with
> only one document to consult and it sounds like the IANA entry will
> need to be amended regardless.
>
> I plan to revise the I-D accordingly unless I hear objections.
>
> Should the Registration Information/Version be incremented to "2" even
> though the identifier semantics/syntax do not change?
>
> My best guess would be "no", but others may chime in with other data.  I'd
start
with leaving it at 1, and seeing if a reason emerges to bump it up.

regards,

Ted Hardie



> Best,
>
> -- Pierre
>
> On Mon, May 2, 2016 at 1:34 PM, Ted Hardie <[e-mail]> wrote:
> > On Mon, May 2, 2016 at 1:11 PM, Pierre-Anthony Lemieux <[e-mail]
> >
> > wrote:
> >>
> >> Hi Ted,
> >>
> >> I appreciate the quick review.
> >>
> >> > Looking through this, it appears that only the process for identifier
> >> > resolution has changed.
> >>
> >> Yes.
> >>
> >> > Given that, a much shorter document updating RFC 7302 noting the
> change
> >> > might be simpler.
> >>
> >> This would require the reader to consult two documents -- not sure
> >> this is fatal however.
> >>
> >> If the "updates" approach is chosen, would IANA [1] continue to
> >> reference RFC 7302, or would instead reference the updated RFC?
> >>
> > It would reference them both; see the dvb entry for an example.
> >
> >>
> >> [1] http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
> >>
> >> > But given the general stability requirements for URNs, highlighting
> that
> >> > the only
> >> > changes are to resolution might be useful.
> >>
> >> If the "obsolete" path is chosen, perhaps there is a way to explicitly
> >> highlight the (very limited) changes, beyond the short description in
> >> the abstract?
> >>
> > You can include an appendix with a list of the changes.  That's
> > non-normative,
> > but it would likely be consulted by anyone who wanted to simply check on
> the
> > relationship between the two.
> >
> >>
> >> IMHO it would be ideal to update RFC 7302 in place, since the changes
> >> do not impact identifier semantics, but this is not possible, right?
> >>
> > That's correct; once issues, RFCs don't change in place.
> >
> > regard,
> >
> > Ted Hardie
> >
> >
> >>
> >> Best,
> >>
> >> -- Pierre
> >>
> >> On Mon, May 2, 2016 at 11:02 AM, Ted Hardie <[e-mail]> wrote:
> >> > Thanks for the pointer.  The RFC series allows a document to update a
> >> > previous document, as well as along one to obsolete a previous
> document.
> >> > Looking through this, it appears that only the process for identifier
> >> > resolution has changed.  Given that, a much shorter document updating
> >> > RFC
> >> > 7302 noting the change might be simpler.
> >> >
> >> > Generally speaking this is a stylistic choice, and there is certainly
> no
> >> > requirement to take that path.  But given the general stability
> >> > requirements
> >> > for URNs, highlighting that the only changes are to resolution might
> be
> >> > useful.
> >> >
> >> > regards,
> >> >
> >> > Ted Hardie
> >> >
> >> > On Sat, Apr 30, 2016 at 2:23 PM, Pierre-Anthony Lemieux
> >> > <[e-mail]>
> >> > wrote:
> >> >>
> >> >> Good morning/evening,
> >> >>
> >> >> Please find at the link below a proposed revision of RFC 7302. This
> >> >> revision adds support for confidential resolution of EIDR Identifiers
> >> >> using HTTP over TLS -- addressing a known limitation of RFC 7302.
> >> >>
> >> >> https://www.ietf.org/id/draft-pal-eidr-urn-2016-00.txt
> >> >>
> >> >> Very much looking forward to your comments and feedback. Let me know
> >> >> if you need additional information.
> >> >>
> >> >> Best,
> >> >>
> >> >> -- Pierre [on behalf of MovieLabs (http://movielabs.com)]
> >> >>
> >> >
> >
> >
>