URN resolution

[Nagwa Abdelghfour <Nagwa.Abdelghfour@eng.sun.com>]

Explanation of how system access to the repository will work in Sun implementation:

The OASIS Repository will support access to the repository by systems
using HTTP, e.g. a parser is validating a document and comes across a
reference to a DTD so it retrieves the DTD from the repository.  System
access is designed for machine to machine vs. human interaction.  RFC
2483 will be used as the model for implementing this feature.  RFC
2483 states:

4.3 I2R (URI to Resource)

          * Name: URI to Resource
          * Mnemonic: I2R
          * Number of Operands: 1
          * Type of Each Operand: First operand is a URI.
          * Format of Each Operand: First operand is encoded as a URI.
          * Algorithm: Opaque
          * Output: An instance of the resource named by the URI.
          * Errors:

        Malformed URI 
        URI is syntactically valid but does not exist in any form. 
        URI exists but there is no available output from this operation. 
        URI existed in the past but nothing is currently known about it. 
        Access denied 

              * Security Considerations:


        Malicious Redirection (see I2L) 
        Denial of Service (see I2L) 

    This operation is used to return a single instance of the resource
    that is named by the URI. The format of the output is
    dependent on the resource itself. 

As HTTP will be the protocol, MIME headers will be used to specify
information about the returned resource such as Content-type:.  Errors
will be mapped to HTTP result codes.  Security concerns will be addressed
by controlling access during the registration process.

Nagwa

--------------------------------------------------------------------------------------------

> From: "Laura Walker" <laura.walker@oasis-open.org>
> To: "ACXO: Advisory Committee for XML.ORG" <xmlorg@lists.oasis-open.org>
> Cc: "Board" <soboard@oasis-open.org>
> Subject: NOTES from 13 March 2000 concall
> Date: Tue, 14 Mar 2000 00:22:40 -0500
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> 
> The following are minutes taken at the 13 March 2000 meeting (a
> teleconference) of the Advisory Committee of XML.ORG (ACXO).
> 
> 
> ACXO Chair: Executive Director of OASIS
> Present:
>  ACXO members:
>    Chair - OASIS Executive Director (Laura Walker)
>    CommerceOne (Terry Allen)
>    DataChannel (Norbert Mikula)
>    Documentum (Una Kearns)
>    IBM (Michael Weiner)
>    Sun Microsystems (Simon Nicholson)
>  Others:
>    Nagwa Abdelefour
>    Jon Bosak
>    Craig Chevrier
> 
> Absent:
>    GCA
>    SoftQuad
> 
> 
> Policy Questions/Issues
> 
> DEFERRED (see note below)
> Q1. What can people submit?
> A1. A package of stuff: schema, related documentation, FAQ, with
> accompanying metadata
> 
> DEFERRED (see note below)
> Q2a. Shall submissions be uniform and if yes, what should they include?
> A2a. - schema
>     - sample instance
>     - supporting documents
> 
> 
> Q3. Is every submission reviewed before being accessible on the repository?
> A3. In the first implementation, there shall be a human review of every
> Submitting Organization (SO) and each submission (initially).
> 
> Q4. Do we allow/enable uniqueness (e.g., by assigning an identifier)?
> A4. Submissions should come in with an identifier (e.g., URNs), there is
> therefore no need for XML.ORG to assign an identifier. RFC2483
> 
> Q5. Are updates allowed?
> A5. We will allow:
>     - Add a new version
>     - Add a new version and it supercedes the old one
>     - Replace a submission (i.e., retraction) --
>       but only through a human review process
>     NOTE: We must decide policy on whether and how
>     reviewer replaces submissions
>     ACTION ITEMS: Write up use cases (ALL: deferred
>     to a future meeting)
> 
> Q6. One contact per submitting organization (SO)?
> A6. Yes. But we must clearly communicate that a SO can be any entity (e.g.,
> a department within a division within a company). This information should be
> presented on the submission form, with some kind of feedback when a
> previously registered SO attempts to register under another contact name
> (e.g., "Sorry: We already have a contact person for this SO. Please try
> another SO.)
> NOTE: must allow some way to update contact person for SO. The RA is
> responsible for authenticating the contact and SO.
> 
> Q8. Taxonomy
> A8. Use what we're using now (NAICS). User should self-classify.
> 
> Q9. Minimum Browser Support
> A9. For submitter - R4.0 and later
>     For browser/user - follow WAI guidelines
> 
> Q10. What should be available for System Download?
> A10. METADATA
> In the first implementation the metadata is available via UI, but may not be
> available for system download (dependent upon development).
> 
> ACTION ITEMS
> - In order to answer Questions 1-2b, all must read T. Allen email of
> Saturday 11 March and Len Gallagher's (NIST) answer to submission content
> question, forwarded by T. Allen on Monday 13 March.
> 
> - Nagwa to write up URN resolution
> 
> 
> 
> "Business Relations" aspects to be discussed
> - To SO: If you need to update your contact person, please call or email.
> -
>