Left open by #13. Issue #9 supplied no answer.
specifications/component/v1/spec.md §5.2 is only this TODO:
TODO — Port range, protocol/visibility interaction, and whether more than one PUBLIC endpoint is permitted.
Why it matters
§5.4 already builds on endpoints: readiness is REQUIRED for a SERVICE exposing at least one PUBLIC endpoint, and a probe naming an endpoint the workload does not declare is ERR_UNKNOWN_ENDPOINT. §5 forbids endpoints outright on a WORKER, JOB and CRON. So the block is constrained from the outside and undefined on the inside.
The concrete questions
- Port range. Is
containerPort bounded? Privileged ports below 1024 are the interesting case — a container that cannot bind one is a deploy-time failure a document could have caught.
- Protocol × visibility. Can a
TCP endpoint be PUBLIC? A public URL implies HTTP routing; if PUBLIC + TCP is meaningless it should be structural, and if it is meaningful the prose should say what it produces.
- More than one
PUBLIC. §5.4 says "at least one PUBLIC endpoint", which reads as though several are permitted. If they are, the component publishes several public URLs and self.publicUrl (component §6.2) is ambiguous. If they are not, that is a structural rule nothing enforces.
Question 3 is the one that reaches furthest — it decides whether a DERIVED output naming the public URL has one referent.
What deciding it costs
All three are structural and all three are narrowing: bounding a port, restricting a protocol/visibility pair, or capping PUBLIC at one rejects documents that validate today. That makes each a major version unless it lands before the first tag. Release PRs #1/#2/#3 are open and no tag exists, so the window is open and closing.
Refs #9
Left open by #13. Issue #9 supplied no answer.
specifications/component/v1/spec.md§5.2 is only this TODO:Why it matters
§5.4 already builds on endpoints:
readinessis REQUIRED for aSERVICEexposing at least onePUBLICendpoint, and a probe naming an endpoint the workload does not declare isERR_UNKNOWN_ENDPOINT. §5 forbidsendpointsoutright on aWORKER,JOBandCRON. So the block is constrained from the outside and undefined on the inside.The concrete questions
containerPortbounded? Privileged ports below 1024 are the interesting case — a container that cannot bind one is a deploy-time failure a document could have caught.TCPendpoint bePUBLIC? A public URL implies HTTP routing; ifPUBLIC+TCPis meaningless it should bestructural, and if it is meaningful the prose should say what it produces.PUBLIC. §5.4 says "at least onePUBLICendpoint", which reads as though several are permitted. If they are, the component publishes several public URLs andself.publicUrl(component §6.2) is ambiguous. If they are not, that is astructuralrule nothing enforces.Question 3 is the one that reaches furthest — it decides whether a
DERIVEDoutput naming the public URL has one referent.What deciding it costs
All three are
structuraland all three are narrowing: bounding a port, restricting a protocol/visibility pair, or cappingPUBLICat one rejects documents that validate today. That makes each a major version unless it lands before the first tag. Release PRs #1/#2/#3 are open and no tag exists, so the window is open and closing.Refs #9