In future azd features, azd will start using the names of services (or elements in azure.yaml) as command targets.

It's important for us to think about what allowed naming characters we should allow. For example, if we allow . characters (which currently breaks parts of azd today -- such as in #3183), we'd have to think about if we ever use . as a property accessor. Example: myapp.api.env would end up being ambiguous for interpretation without escaping.

Early design ideas

We have some prior-art for inspiration from DNS systems, which also influences K8s object names:

DNS Subdomain Names RFC 1123

1. contain no more than 253 characters
2. contain only lowercase alphanumeric characters, '-' or '.'
3. start with an alphanumeric character
4. end with an alphanumeric character

RFC 1123 Label Names - RFC 1123.

1. contain at most 63 characters
2. contain only lowercase alphanumeric characters or '-'
3. start with an alphanumeric character
4. end with an alphanumeric character

RFC 1035 Label Names - RFC 1035.

1. contain at most 63 characters
2. contain only lowercase alphanumeric characters or '-'
3. start with an alphabetic character
4. end with an alphanumeric character

From how azd is commonly used today, we seem to lean towards RFC 1123 label names -- lowercase, dash-separated, alphanumeric characters.

Use cases to consider

The main question to consider is that whether all language developers will overall be comfortable with whatever naming scheme we choose.

I'm opening up this issue for discussion, hoping we can arrive at some level of consensus. The next phase of implementation is likely to implement the naming scheme as a recommendation in the short/near term, and eventually as a restriction in the longer term.