From nobody Tue Aug 25 09:19:11 2020 Return-Path: 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 858233A104A for ; Tue, 25 Aug 2020 09:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=reso-org.20150623.gappssmtp.com 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 8-oMBYpRoWgr for ; Tue, 25 Aug 2020 09:19:07 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B583A0FE4 for ; Tue, 25 Aug 2020 09:19:06 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id s195so7451235ybc.8 for ; Tue, 25 Aug 2020 09:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reso-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3wEMfnMRdSPCMihxxsisWtc54wKzKhvvl7nEYea35/A=; b=xJxGPjBUBjJoxESqKXblckx1FXlnU5YjE51yvoGGyYmU9CgoZQR2K1oSH0ACILqzfW 3awt8/ptuc5h6tBmenzih+6lp4zvbF9nV0sHN1x9BTo4561n+mZrNHtDl+QD0pBv+/hN S0+Ot7xMeZn0GDFDhYqRIEzYgL2Wg7bmDmCPTzPvP5Y+BObqpWlq0IP/CyVw+gd1+Sz3 pn66hXnUwhomkkHhKBXFlwPVGFCKHT9qV9dVcKn1M6EaZ69pOVNSIVcC6jwxBg+94eOz yjvbpjombyhBDT/xN5Ea5H6jujWYZdsZE84ZJhUTQ88Lea6j3i2UdFp+1Jjt0+Cd+Cy2 HziA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3wEMfnMRdSPCMihxxsisWtc54wKzKhvvl7nEYea35/A=; b=mw1kP4mA/6TYeZ5eLNL7Oc1T7cJMv1XGAYE/rc2Zx7+3df1haE/Y4DKKeOMnPHx4bC I9ddgIu8fPm/9O/16QeYuOYM23Gx+oT4Iq6+AjkbR2ueOz37HcByOzbiPZqN+jUoaR+5 4gLvRjPXu2+iH7fZAogoA7jVOSGmvJnZnnDaQry0DNDZLC//uLHXsM+2YV4ATkU1FTkH M2KStNjnWvx2j2KUYWmVe7yUmjcZB5f7U4yFHlu1WTLDqII6s20elQGnJgWQd+OcdOHD aYnKXNfbl5J7UpCUrT/3fpe1+yUfo1BgZ1RkgqXjc735vBn5xqs5umPRRhMN4R2MjzGg +2UQ== X-Gm-Message-State: AOAM531gPw5wWJSBFlyoPenQ5Xf07W2Q7i+As0mBuAGx9g6HJxAYWdl9 ZYYleQ4U8EhHIT+pqb5bIjJYkXo6HL+rP9ZZlAfkxbURTyJj5Bje X-Google-Smtp-Source: ABdhPJxgB/mHs9PjbKjPGViiJGInGZqPGAFTNUGnsEKSm3gQPnOMdwNtJD1yJ0SEB8WkPiqfGrUkYFvgnLSktOR8yug= X-Received: by 2002:a25:bc0b:: with SMTP id i11mr14598241ybh.233.1598372345700; Tue, 25 Aug 2020 09:19:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sam DeBord Date: Tue, 25 Aug 2020 09:18:27 -0700 Message-ID: To: urn@ietf.org Cc: Joshua Darnell Content-Type: multipart/alternative; boundary="000000000000e26fab05adb60fa1" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 16:19:09 -0000 --000000000000e26fab05adb60fa1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:, where 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: where 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 | sam@reso.org 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 > sam@reso.org | 206.658.3225 > > -- > > Namespace Identifier: > > reso > > Version: > > 0.1 > > Date: > > 2020-03-08 > > Registrant: > > Real Estate Standards Organization > > Sam DeBord, CEO > > sam@reso.org =E2=80=93 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 th= e > 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 i= n > 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 t= he > 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 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 , 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 > > > > --000000000000e26fab05adb60fa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on feedback from your members, plea= se see the additional information here, as well as original application bel= ow.=C2=A0

If there are any= further insufficient items, please let us know ASAP and well will make adj= ustments.=C2=A0 Thank you.

Additional information:
Unique Organizationa= l Identifiers
RESO has existing systems=C2=A0which implement = the concept of a=C2=A0Unique Organizational Identifier=C2= =A0(UOI). In this case, the goal is to enumerate the various organizations = affiliated with RESO, both for identification purposes and for use in track= ing their RESO certifications, given that we're a standards body.=C2=A0=

These would have the form=C2=A0urn:reso:uoi:<id>, where=C2=A0= <id>=C2=A0is the assigned identifier in RESO's domain.=C2= =A0

"Organizations" can be multiple list= ing services, brokerages, or any other well-known vendor participating in t= he transaction. UOIs are used in the recording of events as a "recorde= r" of transactional real estate data, both in centralized and decentra= lized systems. We currently have about 800 member organizations, representi= ng the majority of real estate listing transaction=C2=A0originators and pro= cessors in the U.S., and are currently working to expand into other countri= es. We have=C2=A0an=C2=A0event model=C2=A0standard which is currentl= y in DRAFT status and which furthers the notion of these entities as record= ers.


Unique Licensee Identifiers=
We are in the process of developing something called a=C2=A0= Unique Licensee Identifier=C2=A0(ULI). These are a bit different tha= n Unique Organizational Identifiers in the sense that currently in the Unit= ed States there are identifiers assigned by the National Association of Rea= ltors (NRDS numbers) that are supposed to uniquely identify any licensed Re= altor-affiliated member.=C2=A0

There are two issue= s here, a) they often have duplicate numbers and we're looking to de-du= plicate these identifiers into a single, national ID that they can use when= joining brokerages, tracking referrals, or creating transactions, and b) t= here are non-Realtor members who we'd like to assign licenses to as wel= l, which include non-Realtor real estate agents and other service providers= in the transaction such as photographers and assessors. Non-Realtor member= s are not supported within the NRDS=C2=A0framework. We intend to create a r= egistry of these licensees.=C2=A0

Their scheme wou= ld be=C2=A0urn:reso:uli:<id>=C2=A0whe= re=C2=A0<id>=C2=A0is an identifier th= at's guaranteed to be unique within the RESO domain.=C2=A0
ULIs would be used as part of a permanent record in a given tr= ansaction, either in centralized or decentralized systems, to identify the = licensee (or subject) that participated in that transaction.

=

Change Tracking within Real Estate Transaction= s
The majority of RESO's member organizations produce det= ailed transactional histories when data change in their systems, and which = are authoritative throughout the real estate industry and consumed by downs= tream data providers.=C2=A0

RESO provides a standa= rd=C2=A0Data Dictionary=C2=A0which identifies well-known resources, fields, an= d enumerations, as well as various other metadata attached to these entitie= s, and we certify member organizations for their conformance with this mode= l. We're looking to catalog these items with URNs so they may be tracke= d in a reliable and uniform way and recorded during the transaction.
<= div>
For example, if there was a listing price change to a Pr= operty record in a given system, the transactional log would track that as = a change to the following field:=C2=A0urn:reso:met= adata:1.7:property:listprice, where= 1.7 is the version of RESO's metadata that was used in that transactio= n.=C2=A0We 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 severa= l 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 ULI= s, to record robust transactional histories when data change. These metadat= a identifiers would be used both by RESO members and by organizations exter= nal to our domain. This is one reason we'd like to use URNs for trackin= g these metadata, as they provide routing into RESO's ontology in a mea= ningful way.=C2=A0
=C2= =A0
Sam DeBord
CEO=C2=A0|=C2=A0Real Estate Standards Organization=C2=A0=C2= =A0
206.658.3225=C2=A0|=C2=A0sam@reso.org




On Sun, Mar 8, 2020 at 8:58 AM Sam DeBord <sam@reso.org> wrote:
Please see resubmission=C2=A0of nam= espace application=C2=A0below.
=C2=A0
Sam DeBord
CEO = | RESO -=C2=A0Real Estate Standards= Organization=C2=A0=C2=A0
sam@reso.org | 206.658= .3225=C2=A0

--

Namespace Identifier:

=C2=A0 =C2=A0reso

Version:

=C2=A0 =C2=A00.1

Date:

=C2=A0 =C2=A02020-03-08

Registrant:

Real Estate Standards Organization

Sam DeBord, CEO

sam@reso.org =E2=80=93 9= 19.504.9898

Purpose:

The Namespace Identifier (NID) "reso" for Uniform Resource Names<= br> (URNs) will be used to identify resources published by Real Estate Standard= s Organization: RESO <https://reso.org>.


These might include published standards or protocols that RESO
defines and that make use of URNs.=C2=A0 These namespaces are globally uniq= ue.=C2=A0 The URN namespace will be used in public networks by clients to c= onfigure and manage resources in the network.=C2=A0 Servers will enforce th= e uniqueness of the namespaces by using the namespace and the XPath associa= ted with the managed node in the=C2=A0network when accessing a resource.

=C2=A0

Examples of proposed use= s:


=C2=A0

Representation of Unique= Licensee IDs: These will have the form of urn:reso:ulid:x, where x is a specific licensee identifier. Licensees can b= e people like Agents, photographers, appraisers, and others involved in the transaction.

=C2=A0

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 ent= ity in that organization.

=C2=A0

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 o= f 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 th= e form: urn:reso:rid:100222, urn:reso:lfid:302000, and urn:reso:lid:302001, respectively.

Syntax:

=C2=A0 =C2=A0The syntax of Namespace Specific Strings for the "reso&qu= ot; namespace
=C2=A0 =C2=A0is <NSS> in Uniform Resource Names (URNs) [RFC8141].

The entire URN is case-insensitive.

Assignment:

=C2=A0 =C2=A0RESO will maintain the list of registered resources that use t= he
=C2=A0 =C2=A0"reso" NID in the "RESO URN Namespace" standards at
=C2=A0 =C2=A0<https://www.reso.org/>.

=C2=A0 =C2=A0The RESO workgroups describe the <NSS>, how namespaces w= ill be allocated, and how experimental namespaces can
=C2=A0 =C2=A0be used within the allocated URN.

=C2=A0 =C2=A0RESO will manage resource classes using the "reso" N= ID and will be
=C2=A0 =C2=A0the authority for managing resources and associated subsequent=
=C2=A0 =C2=A0strings.=C2=A0 RESO will guarantee the uniqueness of the strin= gs by
=C2=A0 =C2=A0validating them against the existing content of the standards.=
=C2=A0 =C2=A0RESO may also permit secondary responsibility for certain defi= ned
=C2=A0 =C2=A0resources.=C2=A0 Once a subtree assignment is made, it cannot = be
=C2=A0 =C2=A0deleted or reassigned.

=C2=A0 =C2=A0RESO may allow use of experimental type values in specific
=C2=A0 =C2=A0subtrees for testing purposes only.=C2=A0 Note that using experimental
=C2=A0 =C2=A0types may create collision as multiple users may use the same<= br> =C2=A0 =C2=A0values for different resources and specific strings.=C2=A0 All=
=C2=A0 =C2=A0experimentation must follow the guidance set forth in "A Uniform
=C2=A0 =C2=A0Resource Name (URN) Namespace for Examples" [RFC6963].
Security and Privacy:

=C2=A0 =C2=A0There are no additional security considerations other than tho= se
=C2=A0 =C2=A0normally associated with the use and resolution of URNs in gen= eral.

Interoperability:

=C2=A0 =C2=A0There are no known interoperability issues at this time.

Resolution:

=C2=A0 =C2=A0It is not foreseen that URNs within this namespace will underg= o
=C2=A0 =C2=A0resolution.

Documentation:

=C2=A0 =C2=A0Documentation can be found at
=C2=A0 =C2=A0<https://www.reso.org>

=C2=A0

<= /div>
--000000000000e26fab05adb60fa1--