To help with framing this conversation, the changes from RFC 7320 are
highlighted here:
https://www.ietf.org/rfcdiff?url1=rfc7320&url2=draft-nottingham-rfc7320bis-03
I have some rather extensive thoughts on the process of creating bis
documents [1]. While I'm not going to reiterate all of them here, I want
to highlight a specific passage that seems to bear on John's comments:
One major concern that drives these incremental document updates is
that an attempt to republish an RFC as originally described in RFC
2026 can result in such an effort being bogged down by issues that
exist in text unrelated to the desired changes. Such issues can
arise from a change in the consensus of the IETF around best current
practices, such as in the areas of security, privacy, or
architectural design of an underlying protocol. This complication
arises from the fact that processing of an updated full version of an
RFC is procedurally identical to processing of a green-field
definition of a new protocol: review by the IETF at large, and review
by the IESG, are performed on the entire document, leaving legacy
text open to comments that will delay - and occasionally block -
publication of such documents.
/a
____
[1] https://tools.ietf.org/html/draft-roach-bis-documents-00
On 1/7/20 12:57 AM, John C Klensin wrote:
Hi.
My apologies for the extreme lateness of this note. I have
tried to pass URN work on to others since RFCs 8141 and 8254 and
had assumed that someone else would check through this document
to be sure that it appropriately covered both locator-type and
name-type URIs (particularly URNs) (see RFC 3986 Section 1.1.3).
I had assumed that reviews within the ART area and/or a specific
ART Area Review would address that topic but, AFAICT, they may
not have done so.
I've had occasion to look through the document and I'm actually
not sure about the name-locator distinction as it may apply to
it. This note will be short and is rather more about asking the
IESG to be sure that any possible issues are addressed than to
try to do a detailed review of the issues.
AFAICT, the focus of the I-D is to be sure that applications and
elaborations of any URI scheme be firmly under the control and
management of the owner of that scheme and that possible
deviations from that principle are well-controlled.
http://www.w3.org/TR/2004/REC-webarch-20041215, Section 2.2.2.1,
cited in the draft as [webarch] is clear that the ownership of a
URN is delegated to the owners of URN Namespaces rather than
being bound to the "urn" URI scheme itself. I believe it is
possible to read this document in a way that has no impact on
URNs and URN namespaces. However, it appears to me that, if
read without appropriate care, some of the restrictions imposed
on queries and fragments may be inconsistent with mechanisms and
syntax for use in particular URN Namespaces or URNs generally
that were contemplated and extensively discussed during the
development of RFC 8141. Those ideas were deferred by the WG
for future work but the mechanisms may well be in use in
important URN namespaces. Because the last paragraph of Section
1.1 of this I-D essentially declares any existing specification,
even a standards-track one or one adopted by other bodies, that
does not comply with the recommendations of the I-D to be
incorrect and in need of correction, the effects of a reading
that retroactively restricts URN Namespace practices that are
under the control of the Namespace owners could be quite serious.
My preference would be that someone who has been more active
with URN work and Namespace registrations in the last couple of
years do a careful review of the document to determine whether
my concerns justify some tuning of the text. However, given how
late it is in the review process (again, my apologies for not
catching the issue until now), a reasonable alternative would be
to simply insert a sentence early in the I-D that says that it
applies primarily to locator-type URIs although name-type ones
may find it useful as general guidance _or_ to explicitly call
out the difference in ownership between URNs and other URI
schemes.
thanks,
john
p.s. It would be, IMO, helpful if the IESG and the community
would think about the implications of BCP (or IETF-stream
Informational) documents that effectively obsolete or deprecate
existing standards without identifying them or explicitly
updating them and whose responsibility it is to find the
discrepancies.
