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

Fix a grammar mistake in serialization.md and don't imply _ is valid in dns hostnames #163

Closed
wants to merge 1 commit into from

Conversation

jbouzane
Copy link

  • Fix a grammar error ("follow comply" -> "comply")
  • Underscores are invalid in hostnames in DNS; fix the text not to imply they are valid.

Signed-off-by: Jason Bouzane [email protected]

@jonboulle
Copy link
Contributor

Can we reference an RFC(s)? "must follow standard rules" is too vague imho..

@wking
Copy link
Contributor

wking commented Jun 21, 2016

On Tue, Jun 21, 2016 at 02:41:43AM -0700, Jonathan Boulle wrote:

Can we reference an RFC(s)? "must follow standard rules" is too
vague imho..

I'm not sure how specific the hostname restriction is intended to be,
but RFC 5890 probably defines what you need 1. Perhaps the
intention here is to require an LDH label 2?

@philips
Copy link
Contributor

philips commented Jun 22, 2016

+1 on referencing the RFC @jonboulle

@philips
Copy link
Contributor

philips commented Aug 3, 2016

Ping @jbouzane

@philips
Copy link
Contributor

philips commented Aug 10, 2016

@jbouzane Final ping before I take this one over.

@vbatts
Copy link
Member

vbatts commented Aug 10, 2016

Take it over

On Wed, Aug 10, 2016 at 12:55 PM, Brandon Philips [email protected]
wrote:

@jbouzane https://github.com/jbouzane Final ping before I take this one
over.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#163 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEF6bYhmHhJwxPonLCG2pmVRKvXarsmks5qegJygaJpZM4I6gdF
.

@philips philips added this to the v0.5.0 milestone Aug 10, 2016
@philips philips self-assigned this Aug 10, 2016
@jbouzane
Copy link
Author

Please take another look.

@vbatts
Copy link
Member

vbatts commented Aug 19, 2016

@jbouzane lives! 🙌

@vbatts
Copy link
Member

vbatts commented Aug 19, 2016

updates look good, but git commits need a Signed-off-by:

@@ -75,7 +75,7 @@ This specification uses the following terms:
A collection of tags grouped under a common prefix (the name component before <code>:</code>).
For example, in an image tagged with the name <code>my-app:3.1.4</code>, <code>my-app</code> is the <i>Repository</i> component of the name.
A repository name is made up of slash-separated name components, optionally prefixed by a DNS hostname.
The hostname must follow comply with standard DNS rules, but may not contain <code>_</code> characters.
The hostname must comply with standard DNS rules that apply to LDH or IDNA labels as defined in <a href="https://tools.ietf.org/html/rfc5890#section-2.3">RFC 5890</a>.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From RFC 5890, LDH labels include “Fake A-labels”, which I don't think we want to allow (at least, not if we are putting DNS-related constraints on hostnames, which is what this PR is about). Later in the RFC:

For IDNA-aware applications, the three types of valid labels are "A-labels", "U-labels", and "NR-LDH labels", each of which is defined below.

So I think we want to echo that and say:

The hostname must be an A-label, U-label, or NR-LDH label, as defined in RFC 5890.

And we are not supporting binary labels, which RFC 5890 lists as a non-ASCII label not covered under IDNA? I'm personally agnostic on refusing or allowing binary labels, but want to make sure that we're making an explicit decision one way or the other.

@jbouzane jbouzane reopened this Aug 24, 2016
@jbouzane
Copy link
Author

I'll buy that.

@philips
Copy link
Contributor

philips commented Aug 24, 2016

LGTM

Approved with PullApprove

1 similar comment
@vbatts
Copy link
Member

vbatts commented Aug 24, 2016

LGTM

Approved with PullApprove

@@ -75,7 +75,7 @@ This specification uses the following terms:
A collection of tags grouped under a common prefix (the name component before <code>:</code>).
For example, in an image tagged with the name <code>my-app:3.1.4</code>, <code>my-app</code> is the <i>Repository</i> component of the name.
A repository name is made up of slash-separated name components, optionally prefixed by a DNS hostname.
The hostname must follow comply with standard DNS rules, but may not contain <code>_</code> characters.
The hostname must comply with standard DNS rules that apply to IDNA labels as defined in <a href="https://tools.ietf.org/html/rfc5890#section-2.3">RFC 5890</a>.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we want to explicitly list A-label, U-label, or NR-LDH label. Searching the spec for a definition for “IDNA labels” turned up this:

IDNA labels come in two flavors: an ACE-encoded form and a Unicode (native character) form. These are referred to as A-labels and U-labels, respectively…

But I think we want to allow NR-LDH labels as well, because U-labels must contain at least one non-ASCII character, and I'm fine with all-ASCII, non-A label, repository names.

@vbatts
Copy link
Member

vbatts commented Aug 24, 2016

i'm not sure why travis is testing the wrong commit. and why pull-approve seems like it's out for lunch :-\

@wking
Copy link
Contributor

wking commented Aug 24, 2016

On Wed, Aug 24, 2016 at 10:55:21AM -0700, Vincent Batts wrote:

i'm not sure why travis is testing the wrong commit…

The unsigned a52d250 (#188) has landed in master since 9e7f05f's
parent, so Travis is testing that commit because we haven't landed
something like opencontainers/runtime-spec#216 in this repository.

@philips
Copy link
Contributor

philips commented Aug 29, 2016

@caniszczyk I have no idea what is wrong but we can't merge this. Can you force it or something?

@caniszczyk
Copy link
Contributor

@philips I believe the Travis CI build is failing:

a52d250 - FAIL - does not have a valid DCO

@wking
Copy link
Contributor

wking commented Aug 29, 2016

On Mon, Aug 29, 2016 at 09:40:21AM -0700, Chris Aniszczyk wrote:

@philips I believe the Travis CI build is failing:

a52d250 - FAIL - does not have a valid DCO

And that's an already-in-master commit that I don't think we should be
testing for this PR 1.

@philips
Copy link
Contributor

philips commented Aug 31, 2016

@caniszczyk this is the tool messing up. Can you please just force merge this?

@philips
Copy link
Contributor

philips commented Aug 31, 2016

I am going to try and work around this with #226

@philips
Copy link
Contributor

philips commented Aug 31, 2016

Closing in favor of #226 which doesn't have broken travis stuff.

@philips philips closed this Aug 31, 2016
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

Successfully merging this pull request may close these issues.

6 participants