Re: [urn] Namespace application v3: reso

Sam DeBord <> Tue, 17 November 2020 19:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BF193A005D for <>; Tue, 17 Nov 2020 11:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bBNOwU60VqbG for <>; Tue, 17 Nov 2020 11:51:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2E9903A07F9 for <>; Tue, 17 Nov 2020 11:51:38 -0800 (PST)
Received: by with SMTP id i193so20109085yba.1 for <>; Tue, 17 Nov 2020 11:51:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oOKVkUoiCBRspGhvbGhIYQOc7R/L5raEPz4c4AAcvMo=; b=Dlivjtlz9/zRYchyDXM/3lZrke+pH6rZDupHmCCASRusunTqeS05Mq5um1EY70eKJz U9GSZsmU47a+n1FhOLZLDE8++Lu8sPLFua/7pTTa+s9w/NQgp4ogiH8DqMnrYzxlGgEd Z257fw9Vcah7/YiukV3GOCZ5nWsxJyR2OwhIVxG4c7BqP97NSPDoAo0inzlM3wRy32Az SFKag9pas2f/jIFe4eUGoqJ024+z+tgsW1JXknPRLvIfHnGxILM00fxVIiQFomM4T6H2 TbSLcJq6SxkQ57J3yg4i8uAw3C1umZZPNTVDqGBsUzA9mW3yC7Ry+R72i5wHsUzTtDpM AHpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oOKVkUoiCBRspGhvbGhIYQOc7R/L5raEPz4c4AAcvMo=; b=ScpKY9ccST1rvjyBfhcBIE/fFDXkRA1mRY2fDbuDk6/r9JCTX5/a96cEyQEtfjNZaJ lOw/0eieRGv203aEuiaBTDb6kkso+RXLSJ3e3AHg4ggNbQH35OnTm8I5jVE8BKnIJkW4 XUzzhxu050TKAmp3Lob0p6XguYXBzMlfte2kBuUtKcKQpVfX1v46lIiRY7DNZUwY9tyc kdo1qpaLRpcnqlP/Ni8/U74RUaFsC9LLMSgKPJlei59m8e3QCUNSbmE1fqxTFB5gMKbn 3Ocnbi0+u/j3gEHBsrnyeD1nJ4I3YN+krCxi5Ur06nsK8h8ApGLKKx5V030qhdaQhnpU Xr7g==
X-Gm-Message-State: AOAM533v8nhpacPprt1GKpFj/OzYxEvvMveeilvtQz92j5kl2+HhZJGu JSe9Tg7ZJS9idNdA+UdknfRVgSTxXI5mYeVpD6KweGbv7dg=
X-Google-Smtp-Source: ABdhPJxWoAmiCLyK40PzakmVhr2xLlzquVgXU9KSl5ROoQPg5wA0XQ8tfBUm5s6YlEsKa3dW6RdaafvvEM7c0zBgVAk=
X-Received: by 2002:a25:cb11:: with SMTP id b17mr1598914ybg.236.1605642696935; Tue, 17 Nov 2020 11:51:36 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Sam DeBord <>
Date: Tue, 17 Nov 2020 11:51:00 -0800
Message-ID: <>
Cc: Joshua Darnell <>
Content-Type: multipart/alternative; boundary="000000000000965d3e05b452d24d"
Archived-At: <>
Subject: Re: [urn] Namespace application v3: 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, 17 Nov 2020 19:51:48 -0000

Could RESO receive an update on this namespace request? Thank you.

*Sam DeBord*
CEO | Real Estate Standards Organization <>
206.658.3225 |

On Tue, Aug 25, 2020 at 9:18 AM Sam DeBord <> wrote:

> Based on feedback from your members, please see the additional information
> here, as well as original application below.
> If there are any further insufficient items, please let us know ASAP and
> well will make adjustments.  Thank you.
> Additional information:
> *Unique Organizational Identifiers*
> RESO has existing systems which implement the concept of a *Unique
> Organizational Identifier
> <>* (UOI). In this
> case, the goal is to enumerate the various organizations affiliated with
> RESO, both for identification purposes and for use in tracking their RESO
> certifications, given that we're a standards body.
> These would have the form urn:reso:uoi:<id>, where <id> is the assigned
> identifier in RESO's domain.
> "Organizations" can be multiple listing services, brokerages, or any other
> well-known vendor participating in the transaction. UOIs are used in the
> recording of events as a "recorder" of transactional real estate data, both
> in centralized and decentralized systems. We currently have about 800
> member organizations, representing the majority of real estate listing
> transaction originators and processors in the U.S., and are currently
> working to expand into other countries. We have an *event model* standard
> which is currently in DRAFT status and which furthers the notion of these
> entities as recorders.
> *Unique Licensee Identifiers*
> We are in the process of developing something called a *Unique Licensee
> Identifier* (ULI). These are a bit different than Unique Organizational
> Identifiers in the sense that currently in the United States there are
> identifiers assigned by the National Association of Realtors (NRDS numbers)
> that are supposed to uniquely identify any licensed Realtor-affiliated
> member.
> There are two issues here, a) they often have duplicate numbers and we're
> looking to de-duplicate these identifiers into a single, national ID that
> they can use when joining brokerages, tracking referrals, or creating
> transactions, and b) there are non-Realtor members who we'd like to assign
> licenses to as well, which include non-Realtor real estate agents and other
> service providers in the transaction such as photographers and assessors.
> Non-Realtor members are not supported within the NRDS framework. We intend
> to create a registry of these licensees.
> Their scheme would be urn:reso:uli:<id> where <id> is an identifier
> that's guaranteed to be unique within the RESO domain.
> ULIs would be used as part of a permanent record in a given transaction,
> either in centralized or decentralized systems, to identify the licensee
> (or subject) that participated in that transaction.
> *Change Tracking within Real Estate Transactions*
> The majority of RESO's member organizations produce detailed transactional
> histories when data change in their systems, and which are authoritative
> throughout the real estate industry and consumed by downstream data
> providers.
> RESO provides a standard Data Dictionary
> <> which identifies well-known
> resources, fields, and enumerations, as well as various other metadata
> attached to these entities, and we certify member organizations for their
> conformance with this model. We're looking to catalog these items with URNs
> so they may be tracked in a reliable and uniform way and recorded during
> the transaction.
> For example, if there was a listing price change to a Property record in a
> given system, the transactional log would track that as a change to the
> following field: urn:reso:metadata:1.7:property:listprice, where 1.7 is
> the version of RESO's metadata that was used in that transaction. We also
> want to use these identifiers during the Certification process in order to
> record which metadata we found in a given applicant's metadata. We have
> several versions of metadata, and the URN would help us categorize the
> items for each version in a way that's clear to data consumers and
> producers.
> Resource, field, and enumeration-level metadata are intended to be used in
> RESO's Event Model as well, in conjunction with UOIs and ULIs, to record
> robust transactional histories when data change. These metadata identifiers
> would be used both by RESO members and by organizations external to our
> domain. This is one reason we'd like to use URNs for tracking these
> metadata, as they provide routing into RESO's ontology in a meaningful way.
> *Sam DeBord*
> CEO | Real Estate Standards Organization <>
> 206.658.3225 |
> On Sun, Mar 8, 2020 at 8:58 AM Sam DeBord <> wrote:
>> Please see resubmission of namespace application below.
>> *Sam DeBord*
>> CEO | RESO - Real Estate Standards Organization
>> | 206.658.3225
>> --
>> Namespace Identifier:
>>    reso
>> Version:
>>    0.1
>> Date:
>>    2020-03-08
>> Registrant:
>> Real Estate Standards Organization
>> Sam DeBord, CEO
>> – 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 <>.
>> 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
>>    <>.
>>    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
>>    <>