Need to have more detail comment about the format and default values. Plus examples

@freehan @howardjohn what formats should we allow here? I think the label validation that John added is a good start here. Should we limit this to a length shorter than the current 63 characters we get from that validation? Would a protocol ever include non alphanumeric characters? Should we enforce all uppercase or lowercase values so we don't get different https and HTTPS values? I think we agreed that the default value is nil/there isn't one, right?

My naive thought would be to leave the upper limit at 63, require alphanumeric characters only, and require uppercase letters, but I'm very open to other ideas.

@thockin Any thoughts on how we should limit/validate AppProtocol?

My thoughts:

• Length limit - 63 seems reasonable, I cannot imagine needing a longer protocol really and its pretty standard across Kubernetes
• Character set: I assume values like mycompany.com/our-custom-protocol are not something that would really be used here. If that is the case, all uppercase sounds good. We may also want to support a -?

Some examples of things someone might want to set with various constraints:
DNSOVERHTTPS, DNS-OVER-HTTPS, DNS-Over-HTTPS, dns-over-https
HTTP, http
MYSQL, MY-SQL, mySql, mysql

Based on this, I think - is required, but I don't think there is value to mixing cases.

And agree, default value is nil

I think there are 2 options:

1. Treat these as constants. Constants start with capital letters, acronyms are in caps. e.g. HTTP, DNSOverHTTPS, MySQL, MyCustomProtocol

2. Treat this as a label key. Un-prefixed names would be reserved for standardized values, prefixed names would be for non-standard values. E.g. http, dns-over-https, mysql, mycompany.com/my-custom-protocol

I don't think any other options make sense. Between those two, I don't feel VERY strongly - I have a slight lean toward label-style, but it's a little weird if we expect the vast majority of use-cases to be the non-prefixed. Which do we expect more of?

I am not sure that standardized values is the best approach here. There are a lot of protocols out there (wikipedia lists about 50 and there are of course many more less standardized one). I think it would be hard to hit the sweet spot of having the list of "standard" protocols not too small or too large. It would also be a bit awkward UX to be able to specify MySQL but then I have another database and now I have to specify postgresql.org/psql or something. It seems a bit arbitrary. What do you think?

Since the protocol is given meaning by the application consuming it, I think just allowing arbitrary strings here makes the most sense.

I don't have any opinion on the exact character set here though, as long as its not just upper case letters (DNSOVERHTTPS is awkward)

I agree with that. It would be hard to settle on a set of standard app protocols here. Maybe instead it would make sense to have actual validation be limited to a simple character set and max length, but provide guidance on how protocols should be represented. As an example, a potential comment could look like this:

The application protocol for this port.
May contain alphanumeric characters as well as `.`, `-`, and `/`.
Must be no longer than 63 characters.
The following application protocols should consistently be represented as:
- HTTP
- HTTPS
- DNS
...

I don't know, just throwing something out there.

The application protocol for this port.
May contain alphanumeric characters as well as `.`, `-`, and `/`.
Must be no longer than 63 characters.
Examples: HTTP, HTTPS, TCP

Would something like that make sense? It still feels a little weird to have a list of "blessed" protocols, even if its just in the docs. I don't care too much either way though

If the intention is to allow semi-arbitrary strings, the precedent that jumps to mind is Condition Reason:

    Reason string `json:"reason,omitempty" protobuf:"bytes,5,opt,name=reason"`
    // Human-readable message indicating details about last transition.
    // +optional
    Message string `json:"message,omitempty" protobuf:"bytes,6,opt,name=message"`             

In other words, comment that the convention is CamelCase and then don't validate it very much. Validating that it is less than 63 seems appropriate and as for character set, maybe ASCII?

Alternatively, there is a spec for this: https://tools.ietf.org/html/rfc6335

How about we blend ideas. Somethng like:

This field follows standard Kubernetes label syntax.  Un-prefixed names are reserved for IANA standard service names (as per RFC-6335 and http://www.iana.org/assignments/service-names).  Non-standard protocols should use prefixed names.

What do you think?

I think that strikes a great balance here. There's only so much that can be validated, but this provides clear guidance.

Not sure how this file got added in (maybe somewhere in the build process?) but I don't think it should be part of this PR.

Thanks! my ide is dumb and keeps adding this