From 0505c231458107e3d83bf6fb990d24f67156f86e Mon Sep 17 00:00:00 2001 From: Mikhail Mazurskiy Date: Sat, 6 Jan 2018 21:54:57 +1100 Subject: [PATCH] Namespace is a DNS_LABEL --- contributors/design-proposals/architecture/identifiers.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contributors/design-proposals/architecture/identifiers.md b/contributors/design-proposals/architecture/identifiers.md index 977c0c99e..3b8724813 100644 --- a/contributors/design-proposals/architecture/identifiers.md +++ b/contributors/design-proposals/architecture/identifiers.md @@ -55,8 +55,8 @@ suffix) to create a unique Name. For situations where generating a name is impractical, some or all objects may support a param to auto-generate a name. Generating random names will defeat idempotency. * Examples: "guestbook.user", "backend-x4eb1" -2. When an object is created via an API, a Namespace string (a DNS_SUBDOMAIN? -format TBD via #1114) may be specified. Depending on the API receiver, +2. When an object is created via an API, a Namespace string (a DNS_LABEL) +may be specified. Depending on the API receiver, namespaces might be validated (e.g. apiserver might ensure that the namespace actually exists). If a namespace is not specified, one will be assigned by the API receiver. This assignment policy might vary across API receivers (e.g.