Re: Revision of RFC 7302

[Pierre-Anthony Lemieux <[e-mail]>]

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?

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)]
>> >>
>> >
>
>