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

[Adam Montville <[e-mail]>]

Hi Stephen,

Sorry for my delayed response.  I would like to find a convention/specified
way to discover these services.  I like A in that respect.

Adam


On Thu, Dec 8, 2016 at 3:06 PM Banghart, Stephen A. (Fed) <
[e-mail]> wrote:

> 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
> <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.
>
>
> _______________________________________________
> mile mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mile
>