From nobody Tue Nov 17 11:51:50 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 0BF193A005D for ; Tue, 17 Nov 2020 11:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: 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: 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 bBNOwU60VqbG for ; Tue, 17 Nov 2020 11:51:45 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 2E9903A07F9 for ; Tue, 17 Nov 2020 11:51:38 -0800 (PST) Received: by mail-yb1-xb2d.google.com 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; d=reso-org.20150623.gappssmtp.com; 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; d=1e100.net; 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: To: urn@ietf.org Cc: Joshua Darnell Content-Type: multipart/alternative; boundary="000000000000965d3e05b452d24d" 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, 17 Nov 2020 19:51:48 -0000 --000000000000965d3e05b452d24d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Could RESO receive an update on this namespace request? Thank you. *Sam DeBord* CEO | Real Estate Standards Organization 206.658.3225 | sam@reso.org On Tue, Aug 25, 2020 at 9:18 AM Sam DeBord wrote: > Based on feedback from your members, please see the additional informatio= n > 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 othe= r > well-known vendor participating in the transaction. UOIs are used in the > recording of events as a "recorder" of transactional real estate data, bo= th > 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 number= s) > 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 assig= n > licenses to as well, which include non-Realtor real estate agents and oth= er > service providers in the transaction such as photographers and assessors. > Non-Realtor members are not supported within the NRDS framework. We inten= d > 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 transactiona= l > 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 UR= Ns > 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 t= o > 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 i= n > RESO's Event Model as well, in conjunction with UOIs and ULIs, to record > robust transactional histories when data change. These metadata identifie= rs > 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 wa= y. > > *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 the managed node in the network when accessing a resourc= e. >> >> >> >> 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 ca= n >> 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 UR= N >> will take a form of urn:reso:recorder:org:x, where org is an organizatio= n >> id well-known to RESO and x is identifier of the recording entity in tha= t >> organization. >> >> >> >> References to RESO Data Dictionary items: These are already established >> in our ecosystem. This link shows the "Property" resource, which consist= s >> 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 Fiel= d >> 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 >> >> >> >> > --000000000000965d3e05b452d24d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Could RESO receive an update on this namespace request? Th= ank you.
=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
<= br>
<= br>

On Tue, Aug 25, 2020 at 9:18 AM Sam DeBord <sam@reso.org> wrote:
Based on feedback from= your members, please see the additional information here, as well as origi= nal application below.=C2=A0

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

Additional information:
U= nique Organizational Identifiers
RESO has existing systems=C2= =A0which implement the concept of a=C2=A0Unique Organizational Id= entifier=C2=A0(UOI). In this case, the goal is to enumerate the var= ious organizations affiliated with RESO, both for identification purposes a= nd for use in tracking their RESO certifications, given that we're a st= andards body.=C2=A0

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

"Organizations" = can be multiple listing services, brokerages, or any other well-known vendo= r participating in the transaction. UOIs are used in the recording of event= s as a "recorder" of transactional real estate data, both in cent= ralized and decentralized systems. We currently have about 800 member organ= izations, representing the majority of real estate listing transaction=C2= =A0originators and processors in the U.S., and are currently working to exp= and into other countries. We have=C2=A0an=C2=A0event model=C2=A0stan= dard which is currently in DRAFT status and which furthers the notion of th= ese entities as recorders.


Uniqu= e Licensee Identifiers
We are in the process of developing so= mething called a=C2=A0Unique Licensee Identifier=C2=A0(ULI). These a= re a bit different than Unique Organizational Identifiers in the sense that= currently in the United States there are identifiers assigned by the Natio= nal Association of Realtors (NRDS numbers) that are supposed to uniquely id= entify any licensed Realtor-affiliated member.=C2=A0

There are two issues here, a) they often have duplicate numbers and we&#= 39;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 ass= ign licenses to as well, which include non-Realtor real estate agents and o= ther service providers in the transaction such as photographers and assesso= rs. Non-Realtor members are not supported within the NRDS=C2=A0framework. W= e intend to create a registry of these licensees.=C2=A0

Their scheme would be=C2=A0urn:reso:uli:<= id>=C2=A0where=C2=A0<id>=C2= =A0is an identifier that's guaranteed to be unique within the RESO doma= in.=C2=A0

ULIs would be used as part of a permanen= t record in a given transaction, either in centralized or decentralized sys= tems, to identify the licensee (or subject) that participated in that trans= action.


Change Tracking within R= eal Estate Transactions
The majority of RESO's member org= anizations produce detailed transactional histories when data change in the= ir systems, and which are authoritative throughout the real estate industry= and consumed by downstream data providers.=C2=A0

= RESO provides a standard=C2=A0Data Dictionary=C2=A0which identifies well-known= resources, fields, and enumerations, as well as various other metadata att= ached to these entities, and we certify member organizations for their conf= ormance 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 t= he transaction.

For example, if there was a listin= g price change to a Property record in a given system, the transactional lo= g would track that as a change to the following field:=C2=A0urn:reso:metadata:1.7:property:listprice, where 1.7 is the version of RESO's metadata that was u= sed in that transaction.=C2=A0We also want to use these identifiers during the Certification proce= ss in order to record which metadata we found in a given applicant's me= tadata. We have several versions of metadata, and the URN would help us cat= egorize the items for each version in a way that's clear to data consum= ers and producers.

Resource, field, and enumeration-level met= adata are intended to be used in RESO's Event Model as well, in conjunc= tion 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 t= o use URNs for tracking these metadata, as they provide routing into RESO&#= 39;s ontology in a meaningful way.=C2=A0
<= div dir=3D"ltr">
=C2=A0
Sam DeBord
= CEO=C2=A0|=C2=A0Real Estate St= andards Organization=C2=A0=C2=A0
206.658.3225=C2=A0|=C2=A0sam= @reso.org




On Sun, Mar 8, 2020 at 8:58 AM Sa= m DeBord <sam@reso.org= > wrote:
=
Please see resubmission=C2=A0of namespace 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>
--000000000000965d3e05b452d24d-- From nobody Wed Nov 18 19:52:12 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 7BBF83A095F for ; 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 ; 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 ; 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 Cc: urn@ietf.org, josh@reso.org In-Reply-To: (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: 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: Thu, 19 Nov 2020 03:52:12 -0000 Sam DeBord 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 . >>> >>> >>> 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 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 >>>