Re: [urn] Namespace application v2: reso Tue, 21 April 2020 09:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82A443A09CB for <>; Tue, 21 Apr 2020 02:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.095
X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wF7ZKnQOLffk for <>; Tue, 21 Apr 2020 02:13:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF07B3A09C7 for <>; Tue, 21 Apr 2020 02:13:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dbaedf251592; t=1587460393; bh=c0e/ZUI3CI0PKnOCl1P2eUi/dagdoZ7DHnOTjxmf5a0=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=D9wYmGAiFs/yu5itDuP6kwZwBcAhdksSGjVBWea7H0VJOqfcXmV6f3bbvkNbR528Q /TjcSF9x30p8tIkrl66ACqV74kAxmN83HdPKWcRC5dbLp+L1D2B6Mf9jIj06CMbnZ8 CLvfuZhAx917aLILxKhUUekQ4IN05qwERHgafZ3c=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [] ([]) by (3c-app-webde-bap03.server.lan []) (via HTTP); Tue, 21 Apr 2020 11:13:13 +0200
MIME-Version: 1.0
Message-ID: <trinity-f85738f1-06b3-45f1-b3c7-8a6f8e251702-1587460393765@3c-app-webde-bap03>
To: Sam DeBord <>
Cc:, Joshua Darnell <>
Content-Type: text/html; charset="UTF-8"
Date: Tue, 21 Apr 2020 11:13:13 +0200
Importance: normal
Sensitivity: Normal
In-Reply-To: <>
References: <>
X-UI-Message-Type: mail
X-Priority: 3
X-Provags-ID: V03:K1:lgRU/FHzQrj7VaFGstJ7T/xj5QHxeyO22QAQhNzss8oWCgAqXI6i7ZjpdL9LLhdWTwAez wIALcQcObEiYYTm5WJYBnjKTX0R/DgMbu6iq4O5TAvc5nMqp8p2W8KQxspylbHlKtAaQnGdLdIKU xJcEvLUQHMnjWKPsidE54V4ARF1qWGmOuPoO5/TskYrwIU8i2c+0ahYPUL5jchqXFALWKFfSflbn o/5kqS/AlirxmQoVFSJpbJb9dJT0U3zqX4uJvHIRm/NoWTzrTb59H0BOUve2swYBKqfyvTpobE14 Rc=
X-UI-Out-Filterresults: notjunk:1;V03:K0:Rl4gqOWTLgI=:da3rNaGpfdRz+QSKeAkkX/ jncHlpQcvMnYdH/yMLc/gPmvhIBoa97mHiMBR9LXBzDGZ0i53Om5trIU4fj9HwAIRooBRDQh3 ySIs+73mkandZjGeCYsjPAmpyzgt1RzFY9o8ZL96ZBoDSNwJaMsMctuJLZvh4HYhHMvvAtQPl enlLGiA6L+FxvaQrzWJCgdZXHJ1GwiUyOLXqIGIKEFMlO+pNAV8VGPeUOfRQn72BxWwZGt0zE pspa3zyTh/4dinGl0rVKGMOdYm+Oyq/z4oan0uOxPlSLWhAT4ZjrDzuA5OlMPo8hsUX3c5KeI mpLUE3Nju2C/XZvQuYtkNFl5DWzjL/kcpHWlhtLaeD1K3Ho/VV8Nhnft52iBijb5e+Sqe2Mrc BUF0TTiVhtLWmoOZhqkOLGr+OwvAAx2CS8HQWAAbAxHVMGJdbvnYNjq6dN8MfzIW6ZXOaFnh9 VZB6PCiR3XWT+uL07/HWCXHxkq+YcqnuDqOQRt7eVNslOsWotpTWglQXfF51kI2WlgkxrVTeN kAJxfje0sMzjR3bi5DZdcAiSGWqvEF3M3QF3FaV5Ga18V4sNODSowYQJ478DCBBGy1QAL22zG gkf5pK1Z0Hjdc6nYgv1ViGkHiMv2As1LnvEQMi6oSF99B/3236I07egR6qZHVYnlneezzueaX 2u5UFWenw1fnKQFadkMV2jqIppHwYio9vE/jU4xrz9Axh5RqQWyiigqLqTJPI7T+znBM=
Archived-At: <>
Subject: Re: [urn] Namespace application v2: reso
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Apr 2020 09:13:20 -0000

Hi Sam,
looking at your resubmission and the comments by Dale and Juha, I think this registration still needs some work.
1) I agree with Dale that saying that the syntax of the reso-URNs is the same as specified by RFC 8141 is not of much help when someone tries to understand what the different segments of the URN actually mean. From the "examples of proposed use" it seems that you intend to have different branches underneath the NID (you mention "ulid", "recorder" etc.) that would correspond with the "resource classes" mentioned under "assignment". That means that the syntax would be "urn:reso:<resourceClass>:<resourceClassSpecificString>" or something along those lines. And if you intend to publish a registry of those subdivisions somewhere, an explanation and a reference to that registry would be great (I understand that this already applies to the RESO Data Dicstionay Items).
2) I also stumbled over the use of experimental URNs in the RESO namespace. Here you refer to RFC 6963 where it says that
it is NOT RECOMMENDED for implementers to use example URNs
   for any purposes other than documentation, private testing, and truly
   experimental contexts
[1]. If the use is supposed to be trule experimental, I'd discourage to use URNs from the reso namespace in favour of using urn:example. That would keep confusion at a minimum.
Gesendet: Sonntag, 08. März 2020 um 17:58 Uhr
Von: "Sam DeBord" <>
Cc: "Joshua Darnell" <>
Betreff: [urn] Namespace application v2: reso
Please see resubmission of namespace application below.
Sam DeBord
CEO | RESO - Real Estate Standards Organization | 206.658.322

Namespace Identifier:







Real Estate Standards Organization

Sam DeBord, CEO – 919.504.9898


The Namespace Identifier (NID) "reso" for Uniform Resource Names
(URNs) will be used to identify resources published by Real Estate Standards Organization: RESO <" target="_blank" rel="nofollow">>.

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.


   The syntax of Namespace Specific Strings for the "reso" namespace
   is <NSS> in Uniform Resource Names (URNs) [RFC8141].

The entire URN is case-insensitive.


   RESO will maintain the list of registered resources that use the
   "reso" NID in the "RESO URN Namespace" standards at
   <" target="_blank" rel="nofollow">>.

   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.


   There are no known interoperability issues at this time.


   It is not foreseen that URNs within this namespace will undergo


   Documentation can be found at
   <" target="_blank" rel="nofollow">>


_______________________________________________ urn mailing list" target="_blank" rel="nofollow">