Re: [art] Artart last call review of draft-ietf-core-links-json-07

Herbert Van de Sompel <hvdsomp@gmail.com> Tue, 18 April 2017 12:47 UTC

Return-Path: <hvdsomp@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45B312EB88; Tue, 18 Apr 2017 05:47:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 JkQQnjBunmpA; Tue, 18 Apr 2017 05:47:29 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 05FDF12420B; Tue, 18 Apr 2017 05:47:29 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id c45so123688668qtb.1; Tue, 18 Apr 2017 05:47:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lsAj+8l6lI8C4/5VmvmY1YQ0PuxbxkFimPzx4OG+Ucg=; b=kVFBzdI8Y3UxFPQ4GjXLSxNulNR1YSu2SfzzFqQNUhqE6gA1vAjRd5o01rOHd0nkr2 13M6SH4iucDzFh3qSIDYffOIOM/e5km9lAiltLu4uz3ijwfT9z0MIct5SWEwYGl0bHr4 bu5O4HSpP8I1o56sjGLjt22+UPd5tBIE6T4iXDk7pgW6vRuDQUhzkiOU+MXENw7edYS9 dR5OmkiWAdRnEIl58XcnOQPo9cXegxGL5+9Jx68df/DTjTurJDZMimh4jEbR6vz6sDbC 16qiXV0BcAr9HPSBztgmj9RRpYxtnw+3wyckMM4PKkzDfIgHuVF4V/wFuJYMk58NevpH +org==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lsAj+8l6lI8C4/5VmvmY1YQ0PuxbxkFimPzx4OG+Ucg=; b=KoyG2fW14GBjX661JMEBcreXt1stXg6fDfqnpouh+zj87evLXqdPeerOAjTVafXkHW +jn8ing+XbMO3mYSQ3C0e91YfsQYlAYvg+kw8lL90IFNbgtb3XG5sb75EhcHsR+aq5vy Q3w9jEAEafYIeDot1BAOqxAgNMzwbg8ReC9rSQpBR/8cW3ttcADMIFW/BRNrMMHpqXYW 0bX1rJKu0pZclpU7Ydbk3jhBiK8aXy1MAGjCX/9F3v2SzGnQXYb0Lk/zXL/1Q4jqOzsz Wu/rmT0va25mNOVydGNyGW0EIDA7HwpgBnVfzduDJGsW5KZ3AbSE2Bc3CMR7rQjgVMpk uJwQ==
X-Gm-Message-State: AN3rC/40XV7Wzb/BZU4TZ/6sGhyJfb0y61pZHSDWiVUTYHgpgeq/1Vzo 6ck9kpbqab704nMg6Qhy6A9yJg7AGg==
X-Received: by 10.200.36.240 with SMTP id t45mr12970125qtt.230.1492519648189; Tue, 18 Apr 2017 05:47:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.45.162 with HTTP; Tue, 18 Apr 2017 05:47:27 -0700 (PDT)
In-Reply-To: <A12A8CB3-F756-4790-806A-A67AA8CE1D78@tzi.org>
References: <149188258769.15738.17473942496982365590@ietfa.amsl.com> <A12A8CB3-F756-4790-806A-A67AA8CE1D78@tzi.org>
From: Herbert Van de Sompel <hvdsomp@gmail.com>
Date: Tue, 18 Apr 2017 14:47:27 +0200
Message-ID: <CAOywMHdqitw-uN09p11j2xkBK6TO8y3wjAWipK7vhqbTWp0T1w@mail.gmail.com>
Subject: Re: [art] Artart last call review of draft-ietf-core-links-json-07
To: Carsten Bormann <cabo@tzi.org>
Cc: Mark Nottingham <mnot@mnot.net>, art@ietf.org, ietf@ietf.org, "core@ietf.org WG" <core@ietf.org>, draft-ietf-core-links-json.all@ietf.org, Herbert Van de Sompel <hvdsomp@gmail.com>
Content-Type: multipart/alternative; boundary=001a1140eede73628d054d704f68
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vlSgZNVxO4gE_OT4NeBWVM4qAWQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2017 12:47:32 -0000

hi Mark, Carsten,

Sorry to be a bit late to the game.

Two things:

1. I would be very interested in documents serialized according to
application/link-format+json as described in the I-D, especially in the
context of an I-D Erik Wilde and I are authoring regarding Link Sets, see
https://datatracker.ietf.org/doc/draft-wilde-linkset-link-rel/

2. Regarding Mark's comment "This means that any constraints upon RFC6690
documents are also
mirrored into these formats": Mark mentions IRIs as a concern. I am also
concerned about the rules for interpretation of (the Context IRI of) links
as described in Section 2.1 of 6690 (
https://tools.ietf.org/html/rfc6690#section-2.1). It seems to me that these
also introduce constraints that go beyond 5988. I may be mistaken with that
regard because I have never fully understood that section of 6690 (i.e. the
use of "base URI", "origin", "Context URI"). But, when compared to 5988,
the section comes across as imposing constraints that are intended to allow
the straightforward use of relative URIs in constrained environments as a
means to decrease the payload. If my interpretation is correct, then I
would very much favor spec-ing the json link format in terms of 5988 rather
than 6690.

Cheers

Herbert Van de Sompel



On Tue, Apr 11, 2017 at 9:33 AM, Carsten Bormann <cabo@tzi.org> wrote:

> Hi Mark,
>
> thank you a lot for another thoughtful review.
>
> I don’t have an opinion yet on what we should do here, so I’ll supply some
> more background first.
>
> The present spec is first and foremost intended to round-trip with RFC
> 6690, which is indeed stuck a bit on HTTP Link header field syntax.
> However, the way this is used in practice is not meant to inherit the
> complexities of HTTP header field coding.  E.g., for CoRE Resource
> Directory and its DNS-SD compatibility, we want to represent a DNS-SD
> instance identifier (which is UTF-8) as a link attribute.  This is not a
> problem in JSON or CBOR, but also not in the way RFC 6690 is being used,
> i.e. as a UTF-8 based format.
>
> I haven’t checked yet what 5988bis brings to the table and how to track
> this in 6690 or possibly a 6690bis.  There is no point in Big Web and Thing
> Web diverging here, so we should follow the lead.  But maybe that would
> touch both 6690 and the present document once 5988bis is done.
>
> More importantly, we haven’t really put a lot of thinking into IRI
> support.  The CoAP data type “string” which is used for URI components such
> as Uri-Path is UTF-8, so we could embrace them by extending the rules in
> section 6 of RFC 7252 to cover IRIs.  I’m sure that, in practice, CoAP
> implementations already do this — it is not distinguishable in the CoAP
> packet whether the (decomposed) CoAP Uri components have been derived from
> URIs or IRIs.  But the metadata formats (6690 and its JSON/CBOR
> representations; various other JSON and CBOR based formats, e.g. from OCF)
> are still based on RFC 3986 URIs, except where they also use the CoAP
> decomposed form (e.g., CORAL).
>
> While this is outside the scope of the CoRE WG, I personally would like to
> explore how link-format+cbor/+json could be useful for the Big Web.  If
> embracing IRIs there is all we need to make this happen, maybe that can be
> added with a warning that IRIs have to be converted back to URIs for 6690
> link-format.
>
> Grüße, Carsten
>
>
> > On Apr 11, 2017, at 05:49, Mark Nottingham <mnot@mnot.net> wrote:
> >
> > Reviewer: Mark Nottingham
> > Review result: Ready with Issues
> >
> > This specification is a relatively straightforward mapping of the
> > format described in RFC6690 (itself a serialisation of RFC5988bis
> > links) into JSON and CBOR. I don't have deep knowledge of CBOR, but
> > given the editorship of the document, I trust it's seen adequate
> > review in that regard.
> >
> > The only potential issue is how this is achieved. Rather than defining
> > two new serialisations of RFC5988bis links (into JSON and CBOR), it
> > describes how to re-serialise RFC6690 documents into JSON and CBOR.
> > This means that any constraints upon RFC6690 documents are also
> > mirrored into these formats; e.g., the target IRI is constrained to be
> > a URI in 6690, and therefore can also only be a URI in JSON and CBOR,
> > despite these formats' ability to easily convey non-ASCII content.
> >
> > In other words, the specification currently defines these link formats
> > in terms of the Link header (as defined in section 5 of RFC5988) --
> > along with all of the foibles of HTTP header syntax -- rather than
> > their abstract model (defined in Section 3).
> >
> > Whether or not this is a problem depends on what's desired; if 6690 is
> > seen as effectively a profile of 5988, then it makes sense to express
> > it in those terms. If the full range of links capable of being
> > expressed in 5988 is desired, creating new serialisations of 5988
> > links (without a hop through 6690) is preferable.
> >
> > If the current approach is kept, it'd be nice to clarify this
> > situation a bit in the Introduction.
> >
> >
> > _______________________________________________
> > art mailing list
> > art@ietf.org
> > https://www.ietf.org/mailman/listinfo/art
> >
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>



-- 
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orcid.org/0000-0002-0715-6126

==