[OASIS Issue Tracker] (OSLCCCM-9) Do we need to define how how a global configuration provider finds the possible local configuration providers that might contribute to global configurations?

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCCM-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61784#comment-61784 ] 

James Amsden commented on OSLCCCM-9:
------------------------------------

See OSLCCORE-9 (https://issues.oasis-open.org/browse/OSLCCORE-9?jql=project%20%3D%20OSLCCORE) which discusses the issue of bootstrapping discovery, or how clients discover URIs of LDPCs that can then provide additional discovery information.

OSLC Core 3.0 currently reflects the resolution of OSLCCORE-9 (file:///Users/jamsden/Documents/workspace/oslc-core/specs/discovery.html#bootstrappingDiscovery). That resolution concluded that although there may be mechanisms for URI discovery such as HTTP  OPTIONS * or ./well-known (https://tools.ietf.org/html/rfc5785), we did not see a way for a server to provide these URIs when contribution is from plugin extensions.

Servers may need to provide other means of advertising their root URIs, possibly using common URI patterns that append domain prefixes and distinguished resources so clients can predictably guess the root discovery URIs, or provide these URIs in their documentation.

> Do we need to define how how a global configuration provider finds the possible local configuration providers that might contribute to global configurations?
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OSLCCCM-9
>                 URL: https://issues.oasis-open.org/browse/OSLCCCM-9
>             Project: OASIS OSLC Lifecycle Integration for Change and Configuration Management (OSLC CCM) TC
>          Issue Type: Bug
>          Components: Configuration Management
>            Reporter: Nick Crossley
>




--
This message was sent by Atlassian JIRA
(v6.2.2#6258)