Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of urn:li violates RFC 8141 #976

Open
stpeter opened this issue Feb 3, 2024 · 2 comments
Open

Use of urn:li violates RFC 8141 #976

stpeter opened this issue Feb 3, 2024 · 2 comments

Comments

@stpeter
Copy link

stpeter commented Feb 3, 2024

LinkedIn's issuance of Uniform Resource Names (URNs) in the urn:li namespace violates RFC 8141 in several ways.

First, formal URN namespace identifiers should be registered with IANA, but Microsoft has neglected to request addition of "li" to the registry:

https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

Second, RFC 8141 forbids two-character namespace identifiers like "li", since they can conflict with ISO 3166 country codes (and in this case do, since "li" is the country code for Liechtenstein). See in particular section 5.1, which specifies the following constraint on namespace identifiers:

  1. It MUST be more than two characters long, and it MUST NOT start
    with ALPHA ALPHA "-", i.e., any string consisting of two letters
    followed by one hyphen; such strings are reserved for potential
    use as NIDs based on ISO alpha-2 country codes [ISO.3166-1] for
    eventual national registrations of URN namespaces (however, the
    definition and scoping of rules for allocation of responsibility
    for such country-code-based URN namespaces are beyond the scope
    of this document). As a consequence, it MUST NOT start with the
    string "xn--" or any other string consisting of two letters
    followed by two hyphens; such strings are reserved for potential
    representation of DNS A-labels and similar strings in the future
    [RFC5890].

Discussion of this topic is underway on the [email protected] discussion list. The following messages are relevant:

https://mailarchive.ietf.org/arch/msg/urn/x4m6YsxIGJF5R5oxwH6t6urPuqA/

https://mailarchive.ietf.org/arch/msg/urn/B00jD6vT8CQeUIGkaz_jMVFca_E/

https://mailarchive.ietf.org/arch/msg/urn/50HEPE2E4V72HWrAA-LUFl0Dcr8/

https://mailarchive.ietf.org/arch/msg/urn/mmsJ7c8tZdXsQvqPz8B8Kf2aux8/

My apologies if this repository is not the right place to lodge this issue, but the pages at https://learn.microsoft.com/en-us/linkedin/shared/api-guide/concepts/urns?context=linkedin%2Fcontext and https://learn.microsoft.com/en-us/linkedin/shared/references/v2/urn-namespace?context=linkedin%2Fcontext do not state the underlying source in GitHub for their content.

Please engage in this GitHub issue or on the IETF discussion list at https://www.ietf.org/mailman/listinfo/urn to work with the standards community on a solution to this problem.

@albertocavalcante
Copy link

Just curious, where does it live in their code?

@stpeter
Copy link
Author

stpeter commented Sep 24, 2024

@albertocavalcante I'm not sure exactly where it lives, but here are some files in this repository that refer to URNs:

./restli-example-api/src/main/pegasus/com/linkedin/restli/example/Photo.pdl
./restli-example-api/src/main/pegasus/com/linkedin/restli/example/Album.pdl
./restli-int-test/src/test/java/com/linkedin/restli/examples/TestAltKeyResource.java:
./restli-int-test-server/src/main/java/com/linkedin/restli/examples/greetings/server/altkey/StringKeyCoercer.java
./gradle-plugins/src/integTest/groovy/com/linkedin/pegasus/gradle/publishing/PegasusPluginLegacyIvyPublishIntegrationTest.groovy
./gradle-plugins/src/integTest/groovy/com/linkedin/pegasus/gradle/publishing/PegasusPluginIvyPublishIntegrationTest.groovy
./data/src/test/resources/pegasus/com/linkedin/restli/example/Album.pdl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants