Re: [mile] ROLIE Service and Category Document Location Issue
"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Fri, 03 March 2017 06:28 UTC
Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33CE129736 for <mile@ietfa.amsl.com>; Thu, 2 Mar 2017 22:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ofi2mIT8RoOi for <mile@ietfa.amsl.com>; Thu, 2 Mar 2017 22:28:57 -0800 (PST)
Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id ACF541296FA for <mile@ietf.org>; Thu, 2 Mar 2017 22:28:57 -0800 (PST)
Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id v236SrFQ026119; Fri, 3 Mar 2017 15:28:53 +0900 (JST)
Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by gw2.nict.go.jp with ESMTP id v236SrBu026116; Fri, 3 Mar 2017 15:28:53 +0900 (JST)
Received: from VAIO (unknown [133.243.28.221]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPS id 508419DA5; Fri, 3 Mar 2017 15:28:53 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>, "'Banghart, Stephen A. (Fed)'" <stephen.banghart@nist.gov>, mile@ietf.org, alexey.melnikov@isode.com
References: <SN1PR09MB0960603877E8415F6A3A8D0AF0840@SN1PR09MB0960.namprd09.prod.outlook.com> <2b5ba8381eea42549686cfe6c5e63bf3@XCH-ALN-010.cisco.com>
In-Reply-To: <2b5ba8381eea42549686cfe6c5e63bf3@XCH-ALN-010.cisco.com>
Date: Fri, 03 Mar 2017 15:28:52 +0900
Message-ID: <01bc01d293e7$6d1a3c10$474eb430$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHfC+EUyWppBbk3sZNwfEoFaELDXgGugcTCoVw5tPA=
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.7 at zenith2
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/6pCe2ZylJZmQIimNqZGSjqtDLfE>
Subject: Re: [mile] ROLIE Service and Category Document Location Issue
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 06:29:00 -0000
Hi Stephen, I like the option A, but let me ask a clarification questions. In some cases, I've seen a description like the followings in the header section of an HTML page: Case 1: <link rel="alternate" type="application/atom+xml" title="Feed for question 'How To Tell Web Browsers About Atom Feeds'" href="/feeds/question/440391"> Case 2: <link rel="service" type="application/atomsvc+xml" href="http://www.example.org/atomsvc.xml" /> <link rel="service" class="preferred" type="application/atomsvc+xml" href="http://www.example.org/atomsvc.xml" /> I think these descriptions try to identify the location of the service documents. If we find such a description, and if it points to a location that is not the well-known location, are we going to use the pointed location, or are we going to use the well-known location? Thank you, Take From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Panos Kampanakis (pkampana) Sent: Wednesday, January 4, 2017 1:24 AM To: Banghart, Stephen A. (Fed); mile@ietf.org; alexey.melnikov@isode.com Subject: Re: [mile] ROLIE Service and Category Document Location Issue +1 on A. As someone mentioned in IETF97, the /.well-known directory is commonly used in many other occasions. For ROLIE, a /.well-known/rolie/servicedoc or repositorydoc URI would suffice I think. Panos From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Banghart, Stephen A. (Fed) Sent: Thursday, December 08, 2016 4:07 PM To: mile@ietf.org; alexey.melnikov@isode.com Subject: [mile] ROLIE Service and Category Document Location Issue As requested at the IETF 97 MILE meeting, Ive put together some Use Case examples of using service and category documents that highlight the primary differences between the choices for this issue. Those options are: A: Require that ROLIE repositories place the Service and Category documents in a pre-determined location based on a standardized URL template. This location may be a link or redirect to the actual location. B: ROLIE repositories are not required to place their Service and Category documents at a pre-determined location. The use cases below highlight the need for a well-defined location for the service and category documents to support automated discovery. The use cases illustrate that option B is not really an option if our goal is to support automated discovery and use of ROLIE repositories. Feedback on the approaches described below would be appreciated. If you are not a fan of using well-defined URL templates, then alternate proposals that support these automation use cases would also be appreciated. Thanks, Stephen Banghart Defined Service Document and Category Document Location Examples Service Document Use Case: A ROLIE user agent becomes aware of a host (examplesecurityorg.com) that hosts a ROLIE repository. The host is identified by some means, such as by DNS Service Record lookup. However, as the agent only knows the server host name, the agent knows neither the location of the ROLIE feeds nor information about a given feeds contents. Goal: In order to locate the feeds, the operator must find the Atom service document located somewhere on the server. With Defined Location: If the user agent sends a GET request to https://examplesecurityorg.com/rolie/servicedocument, as this is the pre-specified location. This is handled on the server as a redirect to its preferred service document location: https://examplesecurityorg.com/1234/sec/srvdoc. Without Defined Location: The agent must manually search the front-facing section of the site, looking for a stated Atom service document location. Failing that search, the operator must search website documentation or contact admins of the site and request the URL. Neither of these methods support automation and require human interaction. If the URL can be identified using these manual methods, , the agent can now send a GET request to https://examplesecurityorg.com/1234/sec/srvdoc to retrieve the service document. This use case is best supported if the ROLIE repository contents can be discovered in an automatable way. A well-defined location for the service document provides a predictable means for collection discovery as long as the host name of the ROLIE repository is known. Category Document Use Case: A ROLIE user agent wants to programmatically populate a list that contains all of the categories provided by a ROLIE repository. The category list will be used to generate search queries tailored to this repository, as the repository may be using any number of global or local categories, such as information-type. This ROLIE repository is also configured to only allow POST requests if they belong to one of the categories specified in the category document. If the user agent intends to write to this repository it must locate the category document. Goal: The tool needs to know the full list of categories supported by the repository. With Defined Location: The user agent sends a get request to https://examplesecurityorg.com/rolie/categorydocument, and parses it to generate a full list of supported categories. This is handled on the server as a redirect to its preferred category document location: https://examplesecurityorg.com/1234/sec/catdoc. Without Defined Location: If the user agent is only interested in the currently provided categories, it must parse all feeds provided by the repository to generate a list. This activity must be repeated on every connection, incurring a heavy performance and bandwidth cost. If the user agent intends to write to the repository, it must manually search the front-facing section of the site, looking for a stated Atom category document location. Failing that search, the operator must contact admins of the site and request the URL. Neither of these methods support automation and require human interaction. Having completed this task, the agent can now send a GET request to https://examplesecurityorg.com/1234/sec/catdoc. Having a well-defined location for the category document can simplify and optimize category information discovery.
- [mile] ROLIE Service and Category Document Locati… Banghart, Stephen A. (Fed)
- Re: [mile] ROLIE Service and Category Document Lo… Adam Montville
- Re: [mile] ROLIE Service and Category Document Lo… Panos Kampanakis (pkampana)
- Re: [mile] ROLIE Service and Category Document Lo… Takeshi Takahashi