Clarify encoding of colon between scheme and type #361

pombredanne · 2024-12-05T18:26:02Z

The colon separator between scheme and type must not be encoded.

This is also using, a new, and not yet adopted wording for MUST according to its definition in RFC2119 as clarified in RFC8174

Suggested-by: @gernot-h
Reference: #39 (comment)

JMH: Reference: #376

@gernot-h

The colon separator between scheme and type must not be encoded. This is also using, a new, and not yet adopted wording for MUST according to its definition in RFC2119 as clarified in RFC8174 Suggested-by: @gernot-h Reference: #39 (comment) Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

gernot-h · 2024-12-10T08:36:58Z

Great, thx for addressing this! I think this makes very clear that special characters must not be encoded as separators.

gernot-h · 2024-12-10T08:38:39Z

PURL-SPECIFICATION.rst

@@ -247,8 +247,9 @@ Use these rules for percent-encoding and decoding ``purl`` components:
 - the '#', '?', '@' and ':' characters must NOT be encoded when used as
  separators. They may need to be encoded elsewhere


To fully address the confusion of #39, I would probably also change the last sentence in the para before:

Suggested change

separators. They may need to be encoded elsewhere

separators. Some of them need to be encoded elsewhere as specified in the rules below.

I think, this would also make clearer where they need to be encoded.

johnmhoran · 2024-12-11T02:49:25Z

PURL-SPECIFICATION.rst

+- The colon ':' separator between ``scheme`` and ``type`` MUST NOT be encoded.
+  For example, in the PURL snippet ``pkg:npm`` the colon ':' MUST NOT be encoded,
+  and the PURL snippet ``pkg%3Anpm`` is invalid.



@gernot-h @pombredanne Consider adding at the top of the file, perhaps as a new one-line paragraph following the current first paragraph, something along the lines of the following:

This specification uses RFC 2119 (https://datatracker.ietf.org/doc/html/rfc2119), as clarified in RFC 8174 (https://datatracker.ietf.org/doc/html/rfc8174), for the interpretation of certain terms, e.g., MUST NOT.

Or perhaps a slight modification to the example provided by RFC 2119:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, as clarified in RFC 8174.

(Note that the core spec currently contains a great deal of language that will need to be modified to implement RFC 2119/8174.)

pombredanne · 2024-12-18T18:56:20Z

PURL-SPECIFICATION.rst


- the ':' ``scheme`` and ``type`` separator does not need to and must NOT be encoded.
-  It is unambiguous unencoded everywhere
+- The colon ':' separator between ``scheme`` and ``type`` MUST NOT be encoded.


I guess that following @JimFuller-RedHat suggestion in today's triage call #360 ... this could reworded as:

Suggested change

- The colon ':' separator between ``scheme`` and ``type`` MUST NOT be encoded.

- The colon ':' separator between ``scheme`` and ``type`` MUST be used as-is, unencoded.

@JimFuller-RedHat ?

Hehe, I was (badly) trying say that specs typically define grammar, schema and behavior (ex. processing rules) ... in this case I think how you had it is ok though it is easier to define a 'thing' precisely which has the side effect of defining all the things it cannot be ;)

From grammar pov we could define (in EBNF) as a literal colon ... any parser built with such an EBNF would bork on encoded input ... we might suggest defining pre processing rules to normalise odd input into canonical purl. or define a looser grammar allowing encoding though a separate matter altogether.

I would propose:

"Thescheme and type MUST be separated by a colon ':' "

Armed with a grammar (EBNF) and the spec one can discriminate exactly what is intended.

FWIW, wherever encoding is allowed in a pURL we can explicitly state that in the spec and adjust grammar to reflect that though I think the challenge is unpicking pURL set of encoding rules against the general set of encoding rules on URLs (because people use url stuff on pURL).

Maybe with v1 we are bound to explicitly define encoding behaviour - that is a set of processing rules combined with grammar to get what we have today. It might be that we define the grammar in separate section from processing rules in the spec would help untangle - eg. often a spec (with grammar, processing) is not very readable (and spawns 'annotated spec' or tutorials).

Sorry for not being very helpful!

@JimFuller-RedHat

I would propose:

"Thescheme and type MUST be separated by a colon ':' "

clean and neat.

Yet someone would likely immediately bet a nickel that someone else will open an issue asking whether the colon can or must or must not be encoded. ;)

Here is the way out:
We can keep these negative assertions as comments in a new FAQ document. I think that we can create a leaner spec this way.

I think it makes sense for the spec to avoid specifying all the things that it does not support as you rightly suggest, because there is an infinity of these. And we can push "negative" support questions in that FAQ.

So here:

In the spec:

The scheme and type MUST be separated by a colon ':'

In the FAQ:

Q: Is the colon between scheme and type encoded? Or can it be encoded? If yes, how?

A: The spec has no mention of encoding there, so the colon should be used as-is, never encoded and never requiring any decoding since this is not encoded. It is a parsing error if the colon does not come directly after pkg; Lenient parsing tools are welcome to recover from this error to help process and sanitize damaged purls, but that's not a requirement, and not part of the spec.

That approach can become the standard. The spec will be leaner and crisper and a the FAQ comprehensive to address the questions that will come up for sure.

cool ! fantastic suggestion - brevity and conciseness enables implementators to focus ... a good example is the json spec - https://ecma-international.org/wp-content/uploads/ECMA-404_2nd_edition_december_2017.pdf , which only contains normative text ;)

Signed-off-by: John M. Horan <johnmhoran@gmail.com>

johnmhoran · 2024-12-19T02:36:36Z

I added a test for the : between scheme and type. More to follow tomorrow.

- This includes rewriting scheme-related language to remove the use of "not", now addressed in the newly-added FAQ (faq.rst). Signed-off-by: John M. Horan <johnmhoran@gmail.com>

johnmhoran · 2024-12-23T20:51:30Z

I've just pushed a commit that (1) updates the scheme-related sections of the core spec (PURL-SPECIFICATION.rst) inter alia to remove the use of "not" and to address questions that have been raised in the open issues/PRs and (2) provides added details and clarifications (including the use of "not" where helpful) in a new faq.rst.

I look forward to comments and questions, with the goal of finalizing the changes (including added modifications, tests etc. as needed) as part of the 1.0 release. This PR is intended to address only the scheme-related updates, and other updates will be addressed in a similar narrowly-focused manner.

Reference: #376 Reference: #39 (comment) Signed-off-by: John M. Horan <johnmhoran@gmail.com>

johnmhoran · 2025-01-20T03:09:47Z

@matt-phylum @JimFuller-RedHat @pombredanne I've pushed my updates to this scheme-focused PR -- ready for your (and others') reviews and comments. scheme-focused changes made to PURL-SPECIFICATION.rst and test-suite-data.json and a new faq.rst created.

Reference: #39 (comment) Reference: #376 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

Reference: #39 (comment) Reference: #376 Signed-off-by: John M. Horan johnmhoran@gmail.com

pombredanne

Here is some feedback

pombredanne · 2025-02-05T17:49:57Z

PURL-SPECIFICATION.rst

-            pkg:gem/ruby-advisory-db-check@0.12.4
-            pkg://gem/ruby-advisory-db-check@0.12.4
+  - The ``scheme`` is a constant with the value "pkg".
+  - The ``scheme`` and ``type`` MUST be separated by a colon ':'.


Suggested change

- The ``scheme`` and ``type`` MUST be separated by a colon ':'.

- The ``scheme`` MUST be followed by a unencoded colon ':'.

Good suggestion -- change made.

pombredanne · 2025-02-05T17:51:59Z

PURL-SPECIFICATION.rst

-            pkg://gem/ruby-advisory-db-check@0.12.4
+  - The ``scheme`` is a constant with the value "pkg".
+  - The ``scheme`` and ``type`` MUST be separated by a colon ':'.
+  - ``purl`` parsers MUST accept URLs in which the ``scheme`` and colon ':' are


Suggested change

- ``purl`` parsers MUST accept URLs in which the ``scheme`` and colon ':' are

- ``purl`` parsers MUST accept URLs where the ``scheme`` and colon ':' are

Change made.

pombredanne · 2025-02-05T17:54:40Z

PURL-SPECIFICATION.rst

+  - The ``scheme`` and ``type`` MUST be separated by a colon ':'.
+  - ``purl`` parsers MUST accept URLs in which the ``scheme`` and colon ':' are
+    followed by one or more slash '/' characters, such as 'pkg://', and MUST
+    ignore -- i.e., normalize by removing -- all such '/' characters.


Suggested change

ignore -- i.e., normalize by removing -- all such '/' characters.

ignore and remove all such '/' characters.

Good clarification, change made, and I'm making a corresponding change to related language in the FAQ.

pombredanne · 2025-02-05T17:56:44Z

PURL-SPECIFICATION.rst

-For clarity and simplicity a ``purl`` is always an ASCII string. To ensure that
-there is no ambiguity when parsing a ``purl``, separator characters and non-ASCII
-characters must be UTF-encoded and then percent-encoded as defined at::
+For clarity and simplicity, a ``purl`` is always an ASCII string. To ensure that


We need to refactor this section separately. @mprpic volunteered to make this PR.
Let's remove all changes to this Character encoding section from this PR.

@pombredanne I've backed out all of my prior changes to the "Character encoding" section as requested. In light of @mprpic 's PR #389, I've also deleted a reference to the "Character encoding" section in the FAQ and made a few other adjustments.

Reference: #39 Reference: #376 Signed-off-by: John M. Horan johnmhoran@gmail.com

Reference: #376 Reference: #39 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

johnmhoran · 2025-02-06T02:56:07Z

@pombredanne @mprpic I've made the requested changes and some other needed updates, including deleting a reference in the FAQ to the "Character encoding" section in light of @mprpic 's PR #389 (not yet merged as of right now), which deletes the "Character encoding" section.

One thought -- we might want to defer review of this PR until PR #389 has been merged and I can merge the updated master into this branch and push again.

@pombredanne I tried to request a review by you, but given the unusual parentage of this PR, which you opened, GH won't allow me to request your approving review. 🙂

mprpic

LGTM, just some minor nitpicks around consistency.

mprpic · 2025-02-06T18:28:28Z

faq.rst

+  neatly into a component-focused category.
+
+If you have a question about the PURL specification and don't find an answer
+below, you can open an issue `here <https://github.com/package-url/purl-spec/issues/new?template=Blank+issue>`_.


I would probably ditch this paragraph since it's stating something that is hopefully obvious to anyone interacting with this repository.

@mprpic I wholeheartedly agree. 🙂 Will do as soon as we clarify whether to retain (temporarily or otherwise) the current lowercase purl usage in the core spec. (See my comment further below to you and @pombredanne re Ecma TC54-TG2's approval of 'PURL'/'Package-URL'.)

Removed para re opening an issue.

mprpic · 2025-02-06T18:41:09Z

faq.rst

+
+**QUESTION**: Can the ``scheme`` component be followed by a colon and two slashes, like a URI?
+
+No.  Since a Package-URL, or PURL, never contains a URL Authority, its ``scheme`` should not be suffixed with double slash as in 'pkg://' and should use 'pkg:' instead. Otherwise this would be an invalid URI per RFC 3986 at https://tools.ietf.org/html/rfc3986#section-3.3::


Suggested change

No. Since a Package-URL, or PURL, never contains a URL Authority, its ``scheme`` should not be suffixed with double slash as in 'pkg://' and should use 'pkg:' instead. Otherwise this would be an invalid URI per RFC 3986 at https://tools.ietf.org/html/rfc3986#section-3.3::

No. Since a ``purl`` never contains a URL Authority, its ``scheme`` should not be suffixed with double slash as in 'pkg://' and should use 'pkg:' instead. Otherwise this would be an invalid URI per RFC 3986 at https://tools.ietf.org/html/rfc3986#section-3.3::

Changed to 'purl'.

mprpic · 2025-02-06T18:41:28Z

faq.rst

+
+This rule applies to all slash '/' characters between the ``scheme``'s colon separator and the ``type`` component, e.g., ':/', '://', ':///' et al.
+
+In its canonical form, a PURL must not use any such ':/' ``scheme`` suffix and may only use ':' as a ``scheme`` suffix.  This means that:


Suggested change

In its canonical form, a PURL must not use any such ':/' ``scheme`` suffix and may only use ':' as a ``scheme`` suffix. This means that:

In its canonical form, a purl must not use any such ':/' ``scheme`` suffix and may only use ':' as a ``scheme`` suffix. This means that:

Changed to 'purl'.

mprpic · 2025-02-06T18:41:40Z

faq.rst

+
+In its canonical form, a PURL must not use any such ':/' ``scheme`` suffix and may only use ':' as a ``scheme`` suffix.  This means that:
+
+- PURL parsers must accept URLs such as 'pkg://' and must ignore and remove all such '/' characters.


Suggested change

- PURL parsers must accept URLs such as 'pkg://' and must ignore and remove all such '/' characters.

- purl parsers must accept URLs such as 'pkg://' and must ignore and remove all such '/' characters.

Changed to 'purl'.

mprpic · 2025-02-06T18:41:51Z

faq.rst

+In its canonical form, a PURL must not use any such ':/' ``scheme`` suffix and may only use ':' as a ``scheme`` suffix.  This means that:
+
+- PURL parsers must accept URLs such as 'pkg://' and must ignore and remove all such '/' characters.
+- PURL builders should not create invalid URLs with one or more slash '/' characters between 'pkg:' and the ``type`` component.


Suggested change

- PURL builders should not create invalid URLs with one or more slash '/' characters between 'pkg:' and the ``type`` component.

- purl builders should not create invalid URLs with one or more slash '/' characters between 'pkg:' and the ``type`` component.

Changed to 'purl'.

mprpic · 2025-02-06T18:42:21Z

faq.rst

+- PURL parsers must accept URLs such as 'pkg://' and must ignore and remove all such '/' characters.
+- PURL builders should not create invalid URLs with one or more slash '/' characters between 'pkg:' and the ``type`` component.
+
+For example, although these two PURLs are strictly equivalent, the first is in canonical form, while the second -- with a '//' between 'pkg:' and the ``type`` 'gem' -- is an acceptable PURL but is an invalid URI/URL per RFC 3986::


Suggested change

For example, although these two PURLs are strictly equivalent, the first is in canonical form, while the second -- with a '//' between 'pkg:' and the ``type`` 'gem' -- is an acceptable PURL but is an invalid URI/URL per RFC 3986::

For example, although these two purls are strictly equivalent, the first is in canonical form, while the second -- with a '//' between 'pkg:' and the ``type`` 'gem' -- is an acceptable purl but is an invalid URI/URL per RFC 3986::

Changed as suggested.

mprpic · 2025-02-06T18:43:27Z

faq.rst

+
+The "Rules for each ``purl`` component" section provides that "[t]he ``scheme`` MUST be followed by an unencoded colon ':'.
+
+In this case, the colon ':' between ``scheme`` and ``type`` is being used as a separator, and consequently should be used as-is, never encoded and never requiring any decoding. Moreover, it should be a parsing error if the colon ':' does not come directly after 'pkg'.  Tools are welcome to recover from this error to help with damaged PURLs, but that's not a requirement.


Suggested change

In this case, the colon ':' between ``scheme`` and ``type`` is being used as a separator, and consequently should be used as-is, never encoded and never requiring any decoding. Moreover, it should be a parsing error if the colon ':' does not come directly after 'pkg'. Tools are welcome to recover from this error to help with damaged PURLs, but that's not a requirement.

In this case, the colon ':' between ``scheme`` and ``type`` is being used as a separator, and consequently should be used as-is, never encoded and never requiring any decoding. Moreover, it should be a parsing error if the colon ':' does not come directly after 'pkg'. Tools are welcome to recover from this error to help with malformed purls, but that's not a requirement.

Good suggestion -- done.

johnmhoran · 2025-02-06T19:44:16Z

@mprpic Thanks for your comments. While I'm happy to incorporate them, before I do I want to check with you and @pombredanne to make sure that despite Ecma TC54-TG2's 2024-10-11 approval of Package-URL and PURL as the proper capitalization, we want nonetheless to use lowercase purl in the spec. See https://github.com/Ecma-TC54/tg2/blob/main/meetings/2024-10-11.md.

- Adam, Steve, Philippe discussed capitalization (or not) of the word “purl”.
  - Adam: for non-technical writing, we propose Package-URL and PURL.
  - Steve: in favor of this. This group can lead the standardization of the name.
  - Decided: Package-URL and PURL

mprpic · 2025-02-07T16:10:24Z

@johnmhoran Ah, interesting, I didn't realize the decision was to use the upper-case variant. Won't that clash with https://en.wikipedia.org/wiki/Persistent_uniform_resource_locator, which too uses upper-case PURL? Those meeting notes are missing the explanation of why PURL was chosen.

Reference: #376 Reference: #39 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

- Also updated the canonical_purl value for the new colon ':' test object Reference: #376 Reference: #39 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

Reference: #376 Reference: #39 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

johnmhoran · 2025-02-09T02:10:00Z

Thanks for sharing that link @mprpic . I've adopted your suggestions and made a few other changes, will make corresponding changes to my 'type' PR as well.

PURL-SPECIFICATION.rst

We do not want to update this here. See-also: #389 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

pombredanne

Looking ready to merge IMHO.

pombredanne · 2025-02-12T17:29:55Z

I only reverted minor change to the encoding section, so I consider this still approved and will merge.

pombredanne marked this pull request as draft December 5, 2024 18:26

pombredanne mentioned this pull request Dec 5, 2024

Percent encoding spec and : and / #39

Closed

johnmhoran added the Ecma standard Part of the Ecma standard for PURL label Dec 6, 2024

pombredanne mentioned this pull request Dec 8, 2024

Update Test Suite #52

Closed

gernot-h reviewed Dec 10, 2024

View reviewed changes

johnmhoran added the PURL encoding label Dec 11, 2024

johnmhoran reviewed Dec 11, 2024

View reviewed changes

johnmhoran added the PURL component: scheme label Dec 15, 2024

pombredanne commented Dec 18, 2024

View reviewed changes

Add test for colon between scheme and type

0565922

Signed-off-by: John M. Horan <johnmhoran@gmail.com>

Make scheme-related changes to the core spec and address in the new FAQ

64c1f44

- This includes rewriting scheme-related language to remove the use of "not", now addressed in the newly-added FAQ (faq.rst). Signed-off-by: John M. Horan <johnmhoran@gmail.com>

johnmhoran mentioned this pull request Dec 25, 2024

Add RFC 2119/8174 note and convert terms to uppercase as needed #373

Closed

pombredanne mentioned this pull request Jan 8, 2025

Clarify spec for scheme #376

Closed

2 tasks

johnmhoran added 2 commits January 19, 2025 18:32

Update core spec and FAQ

2f491d2

Reference: #376 Reference: #39 (comment) Signed-off-by: John M. Horan <johnmhoran@gmail.com>

Fix formatting of indented blocks

ee8126f

Reference: #376 Reference: #39 (comment) Signed-off-by: John M. Horan <johnmhoran@gmail.com>

johnmhoran marked this pull request as ready for review January 20, 2025 03:02

johnmhoran mentioned this pull request Jan 20, 2025

Clarify spec for type #378

Closed

jkowalleck mentioned this pull request Jan 22, 2025

Clarify spec for subpath #379

Open

8 tasks

johnmhoran added 2 commits January 28, 2025 17:17

Update FAQ format/structure #39

259342e

Reference: #39 (comment) Reference: #376 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

Merge branch 'master' into 39-colon-quoting

7a28a99

Reference: #39 (comment) Reference: #376 Signed-off-by: John M. Horan johnmhoran@gmail.com

pombredanne commented Feb 5, 2025

View reviewed changes

johnmhoran added 2 commits February 5, 2025 16:41

Merge branch 'master' into 39-colon-quoting

1bb78c7

Reference: #39 Reference: #376 Signed-off-by: John M. Horan johnmhoran@gmail.com

Make clarifying changes to the core spec and FAQ #376

40e8b18

Reference: #376 Reference: #39 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

johnmhoran requested a review from mprpic February 6, 2025 02:54

mprpic previously approved these changes Feb 6, 2025

View reviewed changes

johnmhoran added 2 commits February 8, 2025 16:44

Change FAQ references to lowercase 'purl' #376

f6693db

Reference: #376 Reference: #39 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

Merge branch 'master' into 39-colon-quoting #376

a0a3f9a

- Also updated the canonical_purl value for the new colon ':' test object Reference: #376 Reference: #39 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

johnmhoran dismissed mprpic’s stale review via a0a3f9a February 9, 2025 01:44

Remove remainder of FAQ intro block #376

d797952

Reference: #376 Reference: #39 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

johnmhoran requested a review from mprpic February 9, 2025 01:56

Remove 'Components' heading from FAQ #376

2ca3e23

Reference: #376 Reference: #39 Signed-off-by: John M. Horan <johnmhoran@gmail.com>

mprpic previously approved these changes Feb 10, 2025

View reviewed changes

johnmhoran requested a review from jkowalleck February 11, 2025 15:59

jkowalleck previously approved these changes Feb 11, 2025

View reviewed changes

pombredanne commented Feb 12, 2025

View reviewed changes

PURL-SPECIFICATION.rst Outdated Show resolved Hide resolved

Revert changes to Character encoding section

ef81a58

We do not want to update this here. See-also: #389 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>

pombredanne dismissed stale reviews from jkowalleck and mprpic via ef81a58 February 12, 2025 17:20

pombredanne commented Feb 12, 2025

View reviewed changes

pombredanne merged commit 7317d59 into master Feb 12, 2025

pombredanne deleted the 39-colon-quoting branch February 12, 2025 17:30

pombredanne restored the 39-colon-quoting branch February 12, 2025 17:30

pombredanne deleted the 39-colon-quoting branch February 12, 2025 17:30

johnmhoran mentioned this pull request Apr 3, 2025

split test suite #428

Closed

2 tasks

		@@ -247,8 +247,9 @@ Use these rules for percent-encoding and decoding ``purl`` components:
		- the '#', '?', '@' and ':' characters must NOT be encoded when used as
		separators. They may need to be encoded elsewhere

	separators. They may need to be encoded elsewhere
	separators. Some of them need to be encoded elsewhere as specified in the rules below.

	- The colon ':' separator between ``scheme`` and ``type`` MUST NOT be encoded.
	- The colon ':' separator between ``scheme`` and ``type`` MUST be used as-is, unencoded.

	- The ``scheme`` and ``type`` MUST be separated by a colon ':'.
	- The ``scheme`` MUST be followed by a unencoded colon ':'.

	- ``purl`` parsers MUST accept URLs in which the ``scheme`` and colon ':' are
	- ``purl`` parsers MUST accept URLs where the ``scheme`` and colon ':' are

	ignore -- i.e., normalize by removing -- all such '/' characters.
	ignore and remove all such '/' characters.


		QUESTION: Can the ``scheme`` component be followed by a colon and two slashes, like a URI?

		No. Since a Package-URL, or PURL, never contains a URL Authority, its ``scheme`` should not be suffixed with double slash as in 'pkg://' and should use 'pkg:' instead. Otherwise this would be an invalid URI per RFC 3986 at https://tools.ietf.org/html/rfc3986#section-3.3::

	No. Since a Package-URL, or PURL, never contains a URL Authority, its ``scheme`` should not be suffixed with double slash as in 'pkg://' and should use 'pkg:' instead. Otherwise this would be an invalid URI per RFC 3986 at https://tools.ietf.org/html/rfc3986#section-3.3::
	No. Since a ``purl`` never contains a URL Authority, its ``scheme`` should not be suffixed with double slash as in 'pkg://' and should use 'pkg:' instead. Otherwise this would be an invalid URI per RFC 3986 at https://tools.ietf.org/html/rfc3986#section-3.3::


		This rule applies to all slash '/' characters between the ``scheme``'s colon separator and the ``type`` component, e.g., ':/', '://', ':///' et al.

		In its canonical form, a PURL must not use any such ':/' ``scheme`` suffix and may only use ':' as a ``scheme`` suffix. This means that:


		In its canonical form, a PURL must not use any such ':/' ``scheme`` suffix and may only use ':' as a ``scheme`` suffix. This means that:

		- PURL parsers must accept URLs such as 'pkg://' and must ignore and remove all such '/' characters.

	- PURL builders should not create invalid URLs with one or more slash '/' characters between 'pkg:' and the ``type`` component.
	- purl builders should not create invalid URLs with one or more slash '/' characters between 'pkg:' and the ``type`` component.

	For example, although these two PURLs are strictly equivalent, the first is in canonical form, while the second -- with a '//' between 'pkg:' and the ``type`` 'gem' -- is an acceptable PURL but is an invalid URI/URL per RFC 3986::
	For example, although these two purls are strictly equivalent, the first is in canonical form, while the second -- with a '//' between 'pkg:' and the ``type`` 'gem' -- is an acceptable purl but is an invalid URI/URL per RFC 3986::


		The "Rules for each ``purl`` component" section provides that "[t]he ``scheme`` MUST be followed by an unencoded colon ':'.

		In this case, the colon ':' between ``scheme`` and ``type`` is being used as a separator, and consequently should be used as-is, never encoded and never requiring any decoding. Moreover, it should be a parsing error if the colon ':' does not come directly after 'pkg'. Tools are welcome to recover from this error to help with damaged PURLs, but that's not a requirement.

Clarify encoding of colon between scheme and type #361

Clarify encoding of colon between scheme and type #361

Uh oh!

Conversation

pombredanne commented Dec 5, 2024 • edited by johnmhoran Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gernot-h commented Dec 10, 2024

Uh oh!

gernot-h Dec 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JimFuller-RedHat Dec 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johnmhoran commented Dec 19, 2024

Uh oh!

johnmhoran commented Dec 23, 2024

Uh oh!

johnmhoran commented Jan 20, 2025

Uh oh!

pombredanne left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johnmhoran commented Feb 6, 2025

Uh oh!

mprpic left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johnmhoran Feb 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

pombredanne commented Dec 5, 2024 •

edited by johnmhoran

Loading

gernot-h Dec 10, 2024 •

edited

Loading

JimFuller-RedHat Dec 18, 2024 •

edited

Loading

johnmhoran Feb 9, 2025 •

edited

Loading