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
&#39;How To Tell Web Browsers About Atom Feeds&#39;"
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, I’ve 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 feed’s 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.