Re: [mile] ROLIE Service and Category Document Location Issue

["Panos Kampanakis (pkampana)" <[e-mail]>]

+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:[e-mail]] On Behalf Of Banghart, Stephen A. (Fed)
Sent: Thursday, December 08, 2016 4:07 PM
To: [e-mail]; [e-mail]
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<http://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<http://www.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<http://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<http://www.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.