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

Steve Lhomme <slhomme@matroska.org> Thu, 16 July 2020 21:05 UTC

Return-Path: <slhomme@matroska.org>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEED3A0CEC for <cellar@ietfa.amsl.com>; Thu, 16 Jul 2020 14:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5neJLjrnewA2 for <cellar@ietfa.amsl.com>; Thu, 16 Jul 2020 14:05:20 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58AE3A0CEA for <cellar@ietf.org>; Thu, 16 Jul 2020 14:05:19 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id b15so5815359edy.7 for <cellar@ietf.org>; Thu, 16 Jul 2020 14:05:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; 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; d=1e100.net; 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: <3E54D46B-6D44-4095-9A5A-D9FB7CDB0F90@dericed.com>
In-Reply-To: <3E54D46B-6D44-4095-9A5A-D9FB7CDB0F90@dericed.com>
From: Steve Lhomme <slhomme@matroska.org>
Date: Thu, 16 Jul 2020 23:05:07 +0200
Message-ID: <CAOXsMFJpVN+uDkqcNFync2+Zt5j2hUVu1-3AawreA1mYQNeBkA@mail.gmail.com>
To: Dave Rice <dave@dericed.com>
Cc: Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/cslvLodt2wbXci5VQOt9Z5MmRp0>
Subject: Re: [Cellar] namespace considerations for ebml's definition of EBML Schema
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2020 21:05:22 -0000

Hi,

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 https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ would be
the one to use. Or even https://tools.ietf.org/html/rfc8794 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 <dave@dericed.com> 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 <kmoore@amsl.com>
> 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" <superuser@gmail.com>, Steve Lhomme <slhomme@matroska.org>, Dave Rice <dave@dericed.com>, Moritz Bunkus <moritz@bunkus.org>
> Cc: RFC System <rfc-editor@rfc-editor.org>, Alexey Melnikov <aamelnikov@fastmail.fm>, cellar-ads@ietf.org, cellar-chairs@ietf.org, Steven Villereal <villereal@gmail.com>
>
> 3) In the XML Schema for EBML Schema, the URL https://ietf.org/cellar/ebml
> 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 https://ietf.org/cellar/ebml 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 https://ietf.org/cellar/ebml 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 https://ietf.org/cellar/ebml to urn:ietf:params:xml:ns:ebml. This would follow the recommendation at https://tools.ietf.org/html/rfc3470#section-4.9.
>
> Dave Rice
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar



-- 
Steve Lhomme
Matroska association Chairman