Re: [core] Comments on draft-ietf-core-resource-directory-11
peter van der Stok <stokcons@xs4all.nl> Wed, 16 August 2017 07:19 UTC
Return-Path: <stokcons@xs4all.nl>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C9B13263E; Wed, 16 Aug 2017 00:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AUPLnApS7-AL; Wed, 16 Aug 2017 00:19:54 -0700 (PDT)
Received: from lb3-smtp-cloud7.xs4all.net (lb3-smtp-cloud7.xs4all.net [194.109.24.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFC8132645; Wed, 16 Aug 2017 00:19:50 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:207]) by smtp-cloud7.xs4all.net with ESMTPA id hscFdTZcTAr7rhscFd8W5T; Wed, 16 Aug 2017 09:19:48 +0200
Received: from ip565c6c1e.direct-adsl.nl ([86.92.108.30]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 16 Aug 2017 09:19:47 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 16 Aug 2017 09:19:47 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Jim Schaad <ietf@augustcellars.com>
Cc: draft-ietf-core-resource-directory@ietf.org, core@ietf.org
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <008e01d31202$0eea5870$2cbf0950$@augustcellars.com>
References: <008e01d31202$0eea5870$2cbf0950$@augustcellars.com>
Message-ID: <83dfdae55629cc8c18dba0a8fc517fff@xs4all.nl>
X-Sender: stokcons@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfExg5yU09dza9HrZhDXJjJUjYVIYyxL6MV4H7xzmKG/vZAaCZD1aVFru34Qp/G5cYREE7gPBBfklb9cudq56iEHQNqw/cOK9tOXoybm8ytJfpFgzgYW8 BHnDTf54bs8mKayekNdlHTurWmJwuVeM0984V3s673p1iGLYrFeIzUlfD1NrL1YaSFXMMs/3MV6KeW+gGfixAWmg/L2xjv1NWrAZfRVLG5FVLe/gG89fA+aA vf/c758jq7mFjDFRHXrHiQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Z8o6pkGrlE6I3RUaEmIakFnLOS4>
Subject: Re: [core] Comments on draft-ietf-core-resource-directory-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2017 07:19:57 -0000
Hi Jim, thanks for these remarks, they do help in getting the text better. Jim Schaad schreef op 2017-08-10 19:56: > 1. In section 5.2 para 2 - Not sure if this is wrong or not. However > I > would think that rt=core.rd-group is used to discover the URI path for > RD > group operations not rt=core.gp. I note that core.gp is not listed in > the > set of valid rt values in the template. absolutely, spot on. archaeological remains to be removed. > > 2. I am unclear of the proper interactions of the following items: > * The anchor attribute - does it override the context query parameter > * What happens if a full URI is given as the target? How does this > interact w/ the context query parameter? @Michael or @Christian, can you react; my web vocabulary does not always suffice. > > 3. For simple registration. If the client has needed to find the RD > so it > knows where to do the post, why is the post not done to the RD rather > than > to the /.well-know/core point? section 5.3.1 refers to 5.3.2 where the client posts to the RD; and the RD reacts. Do you want more explicit text in 5.3.1? OR 5.3.1 and 5.3.2 integrated? > > 4. It is not clear to me what if the patch payload of {data} should > be > accepted. Looking at the document as JSON, there is always an array > wrapper > around it so that this template never matches the resulting document. > It > seems as if this should always be [{data}] instead. Is there an > implicit > add of the array if absent? If you have a pattern of {data} and you > match > multiple items, is that an error? I'm sorry, not to understand this remark. we refer to section 5.4.4? The template specifies nothing about the payload apart from the format application/merge-patch+json which is defined in RFC 7396. RFC7396 allows arrays and simple objects in curly brackets in the payload Is the example incorrect? Do you want to remove the array brackets because it is a single object? > > 5. Is there an implication that if the resources associated with an > endpoint expire, that the endpoint expires from all of its groups as > well? > Is there a different way that endpoints are registered with the RD? Will put in additional text that removal of endpoint implies removal from groups as well. > > 6. Can an endpoint register zero items with an RD? I expect so. Text can be added that registration of an endpoint with zero links does not create the endpoint. > > 7. should there be some text on interactions between ETag and > page/count > query parameters? What happens if there is a an update of the registry > in > the middle of doing a sequence of queries about the links using these > options? Correct remark. In the CoMI draft I added warning text about interleaving with the block option. Do you consider that a warning note in the text is sufficient? Getting interleavings handled correctly may lead to massive amounts of code (and specification text); so to me a warning seems sufficient. > > > Jim > > > Typo > s/ecample.com/example.com/ Noted > > many thanks, hope this meets your questions (partially) Peter > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core
- [core] Comments on draft-ietf-core-resource-direc… Jim Schaad
- Re: [core] Comments on draft-ietf-core-resource-d… peter van der Stok