Re: [Cellar] namespace considerations for ebml's definition of EBML Schema

Steve Lhomme <> Thu, 16 July 2020 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBEED3A0CEC for <>; Thu, 16 Jul 2020 14:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5neJLjrnewA2 for <>; Thu, 16 Jul 2020 14:05:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C58AE3A0CEA for <>; Thu, 16 Jul 2020 14:05:19 -0700 (PDT)
Received: by with SMTP id b15so5815359edy.7 for <>; Thu, 16 Jul 2020 14:05:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ai/KvBY9gQBzN/u7rlN/Nbm16Z8Fjzuep/21z7tdv8E=; b=tRSEiMGmxfRhBT9csHdPrFH2HbLt0eINe+htI1TWRzPkg/8dIYuQRBkaEDzJkEC7a3 xyESxcKINsoXCiv5NNLSlcb1kdAkaVAFoRDY4wq212CMX5esRc/UzE8OUG3sk1PfQ4xX D1Ph+8gejc6BHZEPd4R82vbVp3tI1/LKaoB+uVS6nnApCJ6BLVxclZPf1fGWwe8oM6FI P+FkzdPCza+BKFnLRQPlpEliEYDHFSSHPVh/BAiueg8hlJtKtvQSea9KFLQ0/XGm+IVV geJ+ngmZT9jurHegGZW5QcfmFHEVAdBL624r6M2gvylByYU4Xza8jGRL8iL7c/DjA+Yl Vepw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ai/KvBY9gQBzN/u7rlN/Nbm16Z8Fjzuep/21z7tdv8E=; b=ME4RdtYRjr+y6/WnAX+cErFzVA+NuAIO+4vqm3zSg5JtNVFxMz8qjhuUjJqyj0O7Mu u8qeNhHebsqQozCXQ6mpheTPwIX6Oe9U/xXLfpBOlFipKPRl9/BJBUSGmI/K8+3Y+OtG zLGos1OKoJeq67wDVHdZPNQvvpCSV6zqD9o8ectAcE95TFh1STWQDHrO3FrTmLWbNvLR iCnrFIh0k7gR3WzTEH14xgTQTxKtkaUMr4umz404USv3KW5LLkCqnKtVTJZWJoRJeN83 sm66okMXpirbpzc0pZ5BcsIzjM3bj8vkW38CSZKd2H1aKJu+DW7tS0w2syh1mF1yvAxB IuxA==
X-Gm-Message-State: AOAM5317pv+znf/8lnkmdS3ALKRzT48N1/BSFJgtLPBtHbTurbR1d8Wx DuNXYh24DLJcgLsfrCgjuIB8G1XilGaz6mLAnUydOvar1GPJRQ==
X-Google-Smtp-Source: ABdhPJyDiNsCv5m7M51WuzxxPnVJJkFgVB48qhvRPNocQ6/kxeJ4YPC2NHB+N8kRahliLrLSigSa69qJdbIJK52pZF4=
X-Received: by 2002:aa7:c353:: with SMTP id j19mr6155366edr.219.1594933517993; Thu, 16 Jul 2020 14:05:17 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Steve Lhomme <>
Date: Thu, 16 Jul 2020 23:05:07 +0200
Message-ID: <>
To: Dave Rice <>
Cc: Codec Encoding for LossLess Archiving and Realtime transmission <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Cellar] namespace considerations for ebml's definition of EBML Schema
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jul 2020 21:05:22 -0000


My understanding is that a HTTP URL with meaningful data about the
format is a plus. But it's not mandatory. It has to be distinct enough
from other namespaces existing in the world. Using a urn: would be
less useful IMO.

If we want to use a better URL that people can refer to in the future
then would be
the one to use. Or even when it's
published. I don't know how permanent the URLs are, and we can never
guarantee a URL will be there in 100 years.

I don't know if the namespace we use in the XSD is normative. But even
if it is the value itself doesn't mean much.

If you want a IETF URN rather than the IETF URL for this RFC, then
"urn:ietf:rfc:8794" sounds nice. It matches the ABNF in RFC648.

I searched all (current) RFCs and there are a few "urn:ietf:rfc" in
them, like in RFC 8759:

  The namespace "urn:ietf:rfc:8759" is as defined by [RFC2648].

There's also "urn:ietf:rfc:7807" and "urn:ietf:rfc:7351".

If this normative we may add a sentence similar to RFC8759. Our text
doesn't imply it's normative:

  The following provides an XML Schema [@!XML-SCHEMA] for facilitating
verification of an EBML Schema described in (#ebml-schema).

Le jeu. 16 juil. 2020 à 20:03, Dave Rice <> a écrit :
> Hi cellar,
> This is a late comment in regards to the EBML document, but I’m considering this dialogue.
> Begin forwarded message:
> From: Karen Moore <>
> Subject: [AD - Murray] Re: AUTH48 [KC][SW]: RFC 8794 <draft-ietf-cellar-ebml-17.txt> NOW AVAILABLE
> Date: July 16, 2020 at 1:53:35 PM EDT
> To: "Murray S. Kucherawy" <>om>, Steve Lhomme <>rg>, Dave Rice <>om>, Moritz Bunkus <>
> Cc: RFC System <>rg>, Alexey Melnikov <>fm>,,, Steven Villereal <>
> 3) In the XML Schema for EBML Schema, the URL
> is provided, but it doesn't seem to be a valid site. Please confirm that this
> is okay.
> -->
> I don't suppose we could host it on the IETF website. I'm not sure if
> a valid URL is necessary here, this is just a marker for a namespace.
> I think it only needs to be unique so that it's not mistaken with an
> XSD with a same name.
> Within the EBML Schema example xml and the EBML Schema XSD the value of is used as an undefined and stand-in namespace. From reviewing other RFCs which define XML Schemas, I see that they don’t use this style of URL but instead use a URN guided by RFC2648.
> Should we consider adding a section such as the one quoted below and changing from to urn:ietf:params:xml:ns:ebml?
> ### `<EBMLSchema>` Namespace
> The namespace URI for elements defined by this specification is a URN as
> defined by [@!RFC2141] that uses the namespace identifier 'ietf' defined by
> [@!RFC2648] and extended by [@!RFC3688]. This URN is:
> ```
> urn:ietf:params:xml:ns:ebml
> ```
> and changing from to urn:ietf:params:xml:ns:ebml. This would follow the recommendation at
> Dave Rice
> _______________________________________________
> Cellar mailing list

Steve Lhomme
Matroska association Chairman