Re: [urn] Namespace application v3: reso

worley@ariadne.com Thu, 19 November 2020 03:52 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBF83A095F for <urn@ietfa.amsl.com>; Wed, 18 Nov 2020 19:52:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.983
X-Spam-Level:
X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0szFzbDccV3O for <urn@ietfa.amsl.com>; Wed, 18 Nov 2020 19:52:09 -0800 (PST)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87E33A0949 for <urn@ietf.org>; Wed, 18 Nov 2020 19:52:09 -0800 (PST)
Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-01v.sys.comcast.net with ESMTP id faVkkdIIZbwH3fazPk4Hw2; Thu, 19 Nov 2020 03:52:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1605757927; bh=WqiOyB2NZ9FPZvey1RGPQOM8yeBpqsNrQT8ClA50x5U=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ffEyr8oWXkOMphTKe8h2+SXQJuh6BYq0ioYBuKmfaHOPzFHEl2knud95TWIUc1yTf 3jteNgR4H0sYX8/Rq5bCUsx3H8gCMEQC/nG1mmo+9vyBjq9SrPPwsDvvhCBVPXqQKR tiqbROUAKwlhFJzYFgIZU005XfroKd2g89MIPtibPpHG+iZQZC01usd1vHW+mfPAPP lEpn+Q/pM9kqYQPuZxYkZryXf4CG23VWKYuo/B/0Wy7fBrUr30UFetCatQtXq9lNb2 V09oAo1tVsjG095nFdVI2q3bbEIe9dZPNJSEzl6PUoXBN2fc9JsZyN0gvlxGQ8daVi GXXIFtG4iIOPg==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-04v.sys.comcast.net with ESMTPA id fazNkbaqckFBlfazOkjYEn; Thu, 19 Nov 2020 03:52:07 +0000
X-Xfinity-VMeta: sc=0.00;st=legit
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0AJ3q56e017176; Wed, 18 Nov 2020 22:52:05 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0AJ3q47P017173; Wed, 18 Nov 2020 22:52:04 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Sam DeBord <sam@reso.org>
Cc: urn@ietf.org, josh@reso.org
In-Reply-To: <CAEKPRhku6Y6nBs3e_ziBzRC8qucFEzeT8k0VoV+ORgAGz6ZW2Q@mail.gmail.com> (sam@reso.org)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Wed, 18 Nov 2020 22:52:04 -0500
Message-ID: <871rgqt34r.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/4NBjsPNrLe1RSyEmdzVNLnAPttg>
Subject: Re: [urn] Namespace application v3: reso
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2020 03:52:12 -0000

Sam DeBord <sam@reso.org> writes:
> Could RESO receive an update on this namespace request? Thank you.

My apologies for neglecting this, especially as I've been one of the
critics of earlier versions.

Looking at the version that accompanied the message I'm responding to.
(For clarity, I copy that part of the message below.)  The future uses
of reso URNs are still rather unformed, but that is quite reasonable
that this stage.  Clearly, you've put thought into how you would use
URNs.  And I think that is sufficient to approve this proposal.

I would suggest you give the text a final careful editing.  E.g., it
contains 'This link shows the "Property" resource', but no link is
given.

Dale

>>> Namespace Identifier:
>>>
>>>    reso
>>>
>>> Version:
>>>
>>>    0.1
>>>
>>> Date:
>>>
>>>    2020-03-08
>>>
>>> Registrant:
>>>
>>> Real Estate Standards Organization
>>>
>>> Sam DeBord, CEO
>>>
>>> sam@reso.org -- 919.504.9898
>>>
>>> Purpose:
>>>
>>> The Namespace Identifier (NID) "reso" for Uniform Resource Names
>>> (URNs) will be used to identify resources published by Real Estate
>>> Standards Organization: RESO <https://reso.org>.
>>>
>>>
>>> These might include published standards or protocols that RESO
>>> defines and that make use of URNs.  These namespaces are globally
>>> unique.  The URN namespace will be used in public networks by clients to
>>> configure and manage resources in the network.  Servers will enforce the
>>> uniqueness of the namespaces by using the namespace and the XPath
>>> associated with the managed node in the network when accessing a resource.
>>>
>>>
>>>
>>> Examples of proposed uses:
>>>
>>>
>>>
>>>
>>> Representation of Unique Licensee IDs: These will have the form of
>>> urn:reso:ulid:x, where x is a specific licensee identifier. Licensees can
>>> be people like Agents, photographers, appraisers, and others involved in
>>> the transaction.
>>>
>>>
>>>
>>> Recorder IDs: These are part of an event model proposal, in which the URN
>>> will take a form of urn:reso:recorder:org:x, where org is an organization
>>> id well-known to RESO and x is identifier of the recording entity in that
>>> organization.
>>>
>>>
>>>
>>> References to RESO Data Dictionary items: These are already established
>>> in our ecosystem. This link shows the "Property" resource, which consists
>>> of fields and enumerations. Each field has a RESO-generated RecordID
>>> associated with it (or LookupID in the case of enumerated values). For
>>> example, the PropertySubType field has a RecordID of 100222, and one of the
>>> allowed values for that field is Apartment, which is part of Lookup Field
>>> ID 302000 and has LookupID 302001. These would have URNs of the form:
>>> urn:reso:rid:100222, urn:reso:lfid:302000, and urn:reso:lid:302001,
>>> respectively.
>>>
>>> Syntax:
>>>
>>>    The syntax of Namespace Specific Strings for the "reso" namespace
>>>    is <NSS> in Uniform Resource Names (URNs) [RFC8141].
>>>
>>> The entire URN is case-insensitive.
>>>
>>> Assignment:
>>>
>>>    RESO will maintain the list of registered resources that use the
>>>    "reso" NID in the "RESO URN Namespace" standards at
>>>    <https://www.reso.org/>.
>>>
>>>    The RESO workgroups describe the <NSS>, how namespaces will be
>>> allocated, and how experimental namespaces can
>>>    be used within the allocated URN.
>>>
>>>    RESO will manage resource classes using the "reso" NID and will be
>>>    the authority for managing resources and associated subsequent
>>>    strings.  RESO will guarantee the uniqueness of the strings by
>>>    validating them against the existing content of the standards.
>>>    RESO may also permit secondary responsibility for certain defined
>>>    resources.  Once a subtree assignment is made, it cannot be
>>>    deleted or reassigned.
>>>
>>>    RESO may allow use of experimental type values in specific
>>>    subtrees for testing purposes only.  Note that using experimental
>>>    types may create collision as multiple users may use the same
>>>    values for different resources and specific strings.  All
>>>    experimentation must follow the guidance set forth in "A Uniform
>>>    Resource Name (URN) Namespace for Examples" [RFC6963].
>>>
>>> Security and Privacy:
>>>
>>>    There are no additional security considerations other than those
>>>    normally associated with the use and resolution of URNs in general.
>>>
>>> Interoperability:
>>>
>>>    There are no known interoperability issues at this time.
>>>
>>> Resolution:
>>>
>>>    It is not foreseen that URNs within this namespace will undergo
>>>    resolution.
>>>
>>> Documentation:
>>>
>>>    Documentation can be found at
>>>    <https://www.reso.org>