<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="info"
     docName="draft-sohail-urn-dnp-00"
     ipr="trust200902"
     obsoletes=""
     updates=""
     submissionType="independent"
     xml:lang="en"
     version="3">

  <front>
    <title abbrev="URN Namespace for DNP">A Uniform Resource Name (URN) Namespace for Digital Nation Pakistan (DNP)</title>
    <seriesInfo name="Internet-Draft" value="draft-sohail-urn-dnp-00" status="informational"/>

    <author fullname="Hira Sohail" initials="H." surname="Sohail" role="editor">
      <organization abbrev="PDA">Pakistan Digital Authority</organization>
      <address>
        <postal>
          <postalLine>4th Floor, 5-A Constitution Avenue</postalLine>
          <postalLine>Sector F-5/1, Islamabad</postalLine>
          <postalLine>Pakistan</postalLine>
        </postal>
        <phone>+92 302 516 1211</phone>
        <email>director-se@pda.gov.pk</email>
        <uri>https://pda.gov.pk/</uri>
      </address>
    </author>

    <date year="2026" month="August" day="5"/>

    <area>ART</area>
    <workgroup>Independent Submission</workgroup>

    <keyword>URN</keyword>
    <keyword>namespace</keyword>
    <keyword>persistent identifier</keyword>
    <keyword>digital public infrastructure</keyword>
    <keyword>Pakistan</keyword>

    <abstract>
      <t>This document describes a Uniform Resource Name (URN) namespace for
      persistent, location-independent identification of normative and
      authoritative publications issued under the Digital Nation Pakistan
      (DNP) programme by the Pakistan Digital Authority (PDA), a federal
      statutory body of the Government of Pakistan established under the
      Digital Nation Pakistan Act, 2025. The namespace covers policies,
      frameworks, technical standards, reference architectures,
      specifications, schemas, application programming interface contracts,
      registries and datasets that PDA issues or is statutorily designated to
      maintain. This document requests registration of the formal Namespace
      Identifier "dnp" in accordance with RFC 8141.</t>
    </abstract>
  </front>

  <middle>

    <section anchor="introduction" numbered="true">
      <name>Introduction</name>

      <t>The Pakistan Digital Authority (PDA) is a federal statutory body of
      the Government of Pakistan, established under the Digital Nation
      Pakistan Act, 2025 <xref target="DNPACT"/>. Its statutory functions
      include the specification of national standards for digital public
      infrastructure, the coordination of digitalisation across federal and
      provincial government entities, and the issuance of the National
      Digital Masterplan and its constituent sectoral plans.</t>

      <t>In discharging those functions PDA issues a growing corpus of
      normative documents. Instruments in this corpus are cited by federal
      and provincial government entities, by regulated private-sector
      participants in Pakistan's digital economy, by procurement and audit
      processes, by academic and policy researchers, and by international
      development partners. Citations to these instruments are expected to
      remain resolvable and unambiguous over periods measured in decades.</t>

      <t>At present those instruments are cited by HTTP URI. Experience in
      Pakistan and elsewhere shows that government HTTP URIs are not durable
      at that timescale: they change when hosting arrangements change, when
      content management systems are replaced, when organisational units are
      renamed or merged, and when domain naming conventions are revised.
      Citations in printed statutory instruments, in signed contracts and in
      the published academic record cannot be revised when this happens. The
      resulting reference decay degrades the evidentiary value of the
      corpus.</t>

      <t>A URN namespace addresses this by separating the identity of an
      instrument from its location. This document defines such a namespace,
      specifies the syntax and assignment rules for names within it, and
      requests registration of the Namespace Identifier (NID) "dnp" as a
      formal URN namespace under <xref target="RFC8141"/>.</t>

      <section anchor="terminology" numbered="true">
        <name>Terminology</name>
        <t>The terms "URN", "NID", "NSS", "assigned-name", "r-component",
        "q-component" and "f-component" are used as defined in
        <xref target="RFC8141"/>.</t>
        <t>The following additional terms are used in this document:</t>
        <dl>
          <dt>instrument:</dt>
          <dd>A discrete normative or authoritative publication issued under
          the DNP programme, considered as a continuing intellectual work
          independent of any particular edition of it.</dd>
          <dt>edition:</dt>
          <dd>A specific, fixed and immutable published state of an
          instrument, as approved and released on a particular date.</dd>
          <dt>the Register:</dt>
          <dd>The authoritative record of names assigned within this URN
          namespace, maintained by PDA as described in
          <xref target="assignment"/>.</dd>
        </dl>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", and "OPTIONAL" in this document are to be interpreted as
        described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
        when, and only when, they appear in all capitals, as shown here.</t>
      </section>

      <section anchor="scope-limits" numbered="true">
        <name>What This Namespace Does Not Cover</name>
        <t>The scope of this namespace is deliberately narrower than the full
        range of Government of Pakistan publications. In particular:</t>
        <ul>
          <li>Names in this namespace <bcp14>MUST NOT</bcp14> be assigned to
          primary legislation of the Islamic Republic of Pakistan. Authority
          over the authoritative text of Acts of Parliament rests with organs
          of the State other than PDA. The "lex" namespace
          <xref target="RFC9676"/> is the appropriate vehicle for legal norms
          and PDA does not seek to displace it.</li>
          <li>Names in this namespace <bcp14>MUST NOT</bcp14> be assigned to
          natural persons, to legal persons, to individual transactions, or
          to any resource whose representation contains personal data. See
          <xref target="security"/>.</li>
          <li>Operational records, case files, correspondence and internal
          working documents of PDA are outside scope. The namespace
          identifies published instruments only.</li>
        </ul>
      </section>
    </section>

    <section anchor="template" numbered="true">
      <name>URN Namespace Definition and Registration Template</name>

      <t>The following registration template conforms to Appendix A of
      <xref target="RFC8141"/>. Sections 3 through 6 of this document expand
      on the Syntax, Assignment, Security and Privacy, and Resolution entries
      of the template and are normative for them.</t>

      <dl newline="true" spacing="normal">
        <dt>Namespace Identifier:</dt>
        <dd>dnp</dd>

        <dt>Version:</dt>
        <dd>1</dd>

        <dt>Date:</dt>
        <dd>2026-08-05</dd>

        <dt>Registrant:</dt>
        <dd>
          <t>Pakistan Digital Authority (PDA)<br/>
          Government of Pakistan<br/>
          4th Floor, 5-A Constitution Avenue, Sector F-5/1<br/>
          Islamabad, Pakistan</t>
          <t>Designated contact: Hira Sohail, Director of Partnerships &amp; Stakeholder Engagement<br/>
          Email: director-se@pda.gov.pk<br/>
          Telephone: +92 302 516 1211<br/>
          Web: https://pda.gov.pk/</t>
          <t>PDA is a federal statutory body established under the Digital
          Nation Pakistan Act, 2025 <xref target="DNPACT"/>, with statutory
          responsibility for national digital standards. PDA is not
          requesting the fast-track registration procedure described in
          Section 6.3 of <xref target="RFC8141"/>; this registration is
          submitted under the Expert Review procedure of Section 6.2.</t>
        </dd>

        <dt>Purpose:</dt>
        <dd>
          <t>Names in this namespace identify normative and authoritative
          instruments published under the Digital Nation Pakistan programme.
          The classes of instrument covered are enumerated in
          <xref target="classes"/> and include national digital policies,
          frameworks, technical standards, reference architectures,
          specifications, implementation guidelines, data schemas,
          application programming interface contracts, public registries,
          published datasets and formal directives issued by PDA.</t>

          <t>The primary community of use is the Government of Pakistan,
          comprising federal ministries and divisions, provincial governments
          and their attached departments and autonomous bodies, together with
          the private-sector entities that build on or must conform to
          Pakistan's digital public infrastructure. Secondary communities of
          use include international standards bodies, multilateral
          development institutions with programmes in Pakistan, comparative
          policy researchers, the archival and library sector, and
          implementers in other jurisdictions who reference Pakistani
          specifications when designing interoperable systems.</t>

          <t>The Internet community at large benefits in three respects.
          First, the corpus is published openly and is of direct interest to
          the growing body of practice on digital public infrastructure, in
          which Pakistan is an adopter and a contributor; stable citation
          makes that corpus usable in the scholarly and technical record.
          Second, Pakistani specifications describe interfaces that non-Pakistani
          systems interoperate with, so unambiguous identification of a specific
          edition of a specification has direct engineering value beyond Pakistan.
          Third, government publications are among the most frequent victims of
          reference decay, and a managed namespace with an explicit
          non-reassignment commitment reduces that decay for a corpus that
          would otherwise be cited by ordinary HTTP URI alone.</t>

          <t>This namespace complements rather than duplicates existing
          namespaces. The "lex" namespace <xref target="RFC9676"/> identifies
          legal norms and is the appropriate identifier system for Pakistani
          legislation, which this namespace does not cover. The "iso" and
          "ietf" namespaces identify the outputs of those bodies; where a DNP
          instrument profiles or adopts such an output it cites it in the
          native namespace rather than reassigning it. Where an instrument is
          also assigned a Digital Object Identifier or, in future, a Pakistani
          National Bibliography Number, those assignments coexist with the URN
          and are recorded as equivalences in the Register; a single resource
          bearing more than one identifier is expressly contemplated by
          Section 5 of <xref target="RFC8141"/>.</t>

          <t>Software that can make use of these names includes citation
          managers and reference-checking tools; document management and
          records systems within government; conformance and procurement
          tooling that must assert which edition of a standard a system was
          built against; long-term digital preservation systems in the
          national archival and library sector; and standards-registry
          software operated by PDA. Resolution services are described in
          <xref target="resolution"/>.</t>

          <t>Neither this namespace nor its definition is expected to become
          a constituent part of a standard developed in the IETF. The
          namespace is expected to be referenced normatively by standards
          issued by PDA itself.</t>
        </dd>

        <dt>Syntax:</dt>
        <dd>See <xref target="syntax"/>.</dd>

        <dt>Assignment:</dt>
        <dd>See <xref target="assignment"/>.</dd>

        <dt>Security and Privacy:</dt>
        <dd>See <xref target="security"/>.</dd>

        <dt>Interoperability:</dt>
        <dd>See <xref target="interop"/>.</dd>

        <dt>Resolution:</dt>
        <dd>See <xref target="resolution"/>.</dd>

        <dt>Documentation:</dt>
        <dd>This document. A stable specification maintained by PDA is
        published at https://standards.dnp.gov.pk/ under the PDA document
        nomenclature framework and is kept synchronised with this
        registration.</dd>

        <dt>Additional Information:</dt>
        <dd>See <xref target="additional"/>.</dd>

        <dt>Revision Information:</dt>
        <dd>None. This is the initial registration.</dd>
      </dl>
    </section>

    <section anchor="syntax" numbered="true">
      <name>Syntax</name>

      <section anchor="abnf" numbered="true">
        <name>Formal Syntax</name>
        <t>Names in this namespace conform to the URN syntax of Section 2 of
        <xref target="RFC8141"/>. The Namespace Specific String (NSS) is
        further constrained as follows, using the Augmented Backus-Naur Form
        of <xref target="RFC5234"/>. The rules ALPHA and DIGIT are imported
        from <xref target="RFC5234"/>.</t>

        <sourcecode type="abnf"><![CDATA[
  NSS         = class ":" local-id [ ":" edition ]

  class       = 2*24( lowalpha )

  local-id    = id-start *62( id-char ) id-end
  id-start    = ALPHA / DIGIT
  id-char     = ALPHA / DIGIT / "-" / "."
  id-end      = ALPHA / DIGIT

  edition     = ver-form / date-form
  ver-form    = "v" 1*3DIGIT [ "." 1*3DIGIT ]
  date-form   = 4DIGIT "-" 2DIGIT "-" 2DIGIT

  lowalpha    = %x61-7A     ; a-z
        ]]></sourcecode>

        <t>The NSS contains at most two colon characters and consists of
        exactly two or three fields. No structure is implied by the colon
        beyond the field division defined above; consistent with Section 5 of
        <xref target="RFC8141"/>, the NSS is to be read as a whole and this
        section is the sole source of its internal structure.</t>

        <t>Every character permitted by the grammar above is a member of the
        "pchar" production of <xref target="RFC3986"/> and requires no
        percent-encoding. Names in this namespace therefore never contain
        percent-encoded octets. A candidate name containing a percent
        character is malformed and <bcp14>MUST</bcp14> be rejected rather
        than decoded.</t>

        <t>Characters outside the ASCII range <bcp14>MUST NOT</bcp14> appear
        in names in this namespace. PDA publishes in Urdu and in English and
        publishes titles and descriptive metadata in both; those titles are
        metadata carried in the Register and in resolution responses, and are
        not part of the identifier. This restriction follows the
        recommendation in Section 2.2 of <xref target="RFC8141"/> that URN
        namespaces avoid non-ASCII characters unless the nature of the
        namespace makes them necessary, and it eliminates a class of
        homograph confusion described in <xref target="security"/>.</t>
      </section>

      <section anchor="classes" numbered="true">
        <name>The class Field</name>
        <t>The class field states the kind of instrument identified. The
        initial set of registered classes is:</t>

        <table anchor="class-table">
          <name>Initially Registered Classes</name>
          <thead>
            <tr><th>class</th><th>Kind of instrument</th></tr>
          </thead>
          <tbody>
            <tr><td>policy</td><td>A national digital policy instrument approved through the applicable governmental process</td></tr>
            <tr><td>framework</td><td>A structuring instrument that organises a domain without itself imposing conformance requirements</td></tr>
            <tr><td>standard</td><td>A technical standard against which conformance can be asserted and assessed</td></tr>
            <tr><td>architecture</td><td>A reference architecture</td></tr>
            <tr><td>specification</td><td>A functional or technical specification for a system, service or component</td></tr>
            <tr><td>guideline</td><td>Non-binding implementation guidance</td></tr>
            <tr><td>directive</td><td>A formal instruction issued by PDA under its statutory powers</td></tr>
            <tr><td>schema</td><td>A data schema, vocabulary or code list</td></tr>
            <tr><td>api</td><td>An application programming interface contract</td></tr>
            <tr><td>registry</td><td>A public registry maintained by or on behalf of PDA</td></tr>
            <tr><td>dataset</td><td>A published dataset</td></tr>
            <tr><td>masterplan</td><td>The National Digital Masterplan and its constituent sectoral plans</td></tr>
            <tr><td>publication</td><td>A report, study or other authoritative publication not falling within another class</td></tr>
          </tbody>
        </table>

        <t>The set of classes is closed at any given time and is extended only
        by amendment to the PDA specification referenced in the Documentation
        entry of <xref target="template"/>. A class, once registered,
        <bcp14>MUST NOT</bcp14> be withdrawn or redefined; a class that
        ceases to be used for new assignments is marked closed in the
        Register and the names already assigned within it remain valid.
        Adding a class does not require revision of this URN namespace
        registration, because it does not alter the syntax, the assignment
        authority or the persistence commitment. PDA publishes the current
        set of classes at the location given in the Documentation entry.</t>
      </section>

      <section anchor="localid" numbered="true">
        <name>The local-id Field</name>
        <t>The local-id field carries the identifier already assigned to the
        instrument under PDA's internal document nomenclature framework,
        transformed to lower case. Where an instrument has no such identifier,
        local-id is a mnemonic assigned by PDA at the time of first
        publication. In either case local-id is unique within its class and,
        once assigned, is never reassigned.</t>
        <t>local-id identifies the instrument as a continuing work. It does
        not, and is not intended to, encode the subject matter, the issuing
        organisational unit, the publication date or the status of the
        instrument. Consumers <bcp14>MUST NOT</bcp14> parse local-id for
        such information; that information is metadata and is obtained from
        the Register.</t>
      </section>

      <section anchor="editions" numbered="true">
        <name>The edition Field and the Work/Edition Distinction</name>

        <t>The optional edition field distinguishes two things that are
        deliberately identified separately, and understanding this
        distinction is necessary to using the namespace correctly.</t>

        <t>A name without an edition field identifies the instrument as a
        continuing work: the standard, the policy or the framework as an
        institutional object that persists across successive revisions. Such
        a name is appropriate where the citing party means "this instrument,
        whichever edition is current" -- for example in a statutory
        instrument that requires conformance with a named standard as
        amended from time to time.</t>

        <t>A name with an edition field identifies one fixed, immutable
        published state of that instrument. Such a name is appropriate where
        the citing party means "this exact text" -- for example in a
        conformance assertion, a procurement specification, a signed
        contract, or a scholarly citation.</t>

        <t>Both forms are permanent and neither is ever reassigned. The
        work-level name continues to identify the same work even after every
        edition of it has been superseded, and continues to identify it after
        the work is withdrawn from current effect; withdrawal is a change of
        status recorded in the Register, not a change of identity. An
        edition-level name continues to identify the same fixed text
        indefinitely, including after that text has been superseded. Neither
        form is ever deleted from the Register.</t>

        <t>The two forms are distinct names identifying distinct resources
        and are not URN-equivalent to one another. Resolution behaviour for
        each form is specified in <xref target="resolution"/>.</t>

        <t>Two edition forms are provided. The ver-form is used where the
        instrument carries an editorial version number, which is the normal
        case for standards and specifications. The date-form, expressed as a
        calendar date in the Gregorian calendar in the format YYYY-MM-DD,
        is used where the instrument is identified by its date of issue
        rather than by a version number, which is the normal case for
        directives and for datasets published on a recurring cycle. A given
        instrument uses one form or the other consistently throughout its
        life; the form in use for an instrument is recorded in the
        Register.</t>

        <t>Examples appear in <xref target="examples"/>.</t>
      </section>

      <section anchor="equivalence" numbered="true">
        <name>URN-Equivalence</name>
        <t>Two names in this namespace are URN-equivalent if they are
        URN-equivalent under the procedure in Section 3.1 of
        <xref target="RFC8141"/> after additionally applying ASCII case
        folding to the entire NSS.</t>
        <t>That is, in addition to the case-insensitivity of the "urn" scheme
        and of the NID that Section 3.1 already provides, the NSS in this
        namespace is case-insensitive. The names</t>
        <ul empty="true">
          <li>urn:dnp:standard:dnp-d.002:v1</li>
          <li>urn:dnp:standard:DNP-D.002:v1</li>
          <li>URN:DNP:STANDARD:DNP-D.002:V1</li>
        </ul>
        <t>are URN-equivalent to one another.</t>
        <t>Because names in this namespace never contain percent-encoded
        octets (<xref target="abnf"/>), the percent-encoding provisions of
        Section 3.1 of <xref target="RFC8141"/> have no effect here. No
        further equivalence rules are defined. In particular, hyphens and
        full stops within local-id are significant and are not elided for
        comparison purposes.</t>
        <t>This rule has the effect only of eliminating false negatives
        relative to the base procedure, as required by Section 3.1 of
        <xref target="RFC8141"/>. It does not cause any two names to be
        treated as distinct that the base procedure treats as
        URN-equivalent.</t>
        <t>PDA assigns names in lower case, and the lower-case form is
        canonical. Applications <bcp14>SHOULD</bcp14> present names in the
        canonical form.</t>
      </section>

      <section anchor="components" numbered="true">
        <name>r-components, q-components and f-components</name>
        <t>This namespace defines no r-component semantics. Consistent with
        the guidance in Section 2.3.1 of <xref target="RFC8141"/>, PDA does
        not use r-components and will not do so before their semantics are
        standardised. A PDA resolver presented with an r-component
        <bcp14>MUST</bcp14> ignore it and resolve the assigned-name.</t>
        <t>This namespace defines no q-component semantics of its own. Where
        a name resolves to a URI that is a locator, a q-component is handled
        as described in Section 2.3.2 of <xref target="RFC8141"/>. PDA
        resolution does not require q-component information and
        <bcp14>MUST NOT</bcp14> be designed to depend on it.</t>
        <t>f-components are interpreted per Section 2.3.3 of
        <xref target="RFC8141"/>, that is, according to the media type of the
        retrieved representation. Where PDA publishes an instrument in HTML,
        it <bcp14>SHOULD</bcp14> provide stable fragment identifiers
        corresponding to the numbered clauses of the instrument, so that a
        clause-level citation such as
        urn:dnp:standard:dnp-x.001:v2#clause-4.3 is durable. Such fragment
        identifiers are a property of the published representation, not of
        the namespace, and are not taken into account for URN-equivalence.</t>
      </section>

      <section anchor="examples" numbered="true">
        <name>Examples</name>
        <t>The following illustrate the syntax. They are not assignments.</t>
        <ul empty="true">
          <li>urn:dnp:standard:dnp-x.001 -- a nomenclature standard, as a continuing work</li>
          <li>urn:dnp:standard:dnp-x.001:v2 -- the second edition of that standard, as a fixed text</li>
          <li>urn:dnp:architecture:dnp-d.002:v1 -- the first edition of a reference architecture</li>
          <li>urn:dnp:masterplan:ndmp-2026-2035 -- the National Digital Masterplan as a work</li>
          <li>urn:dnp:masterplan:ndmp-2026-2035:v1 -- its first published edition</li>
          <li>urn:dnp:directive:pda-2026-014:2026-03-11 -- a directive identified by date of issue</li>
          <li>urn:dnp:schema:person-name:v1 -- the first edition of a data schema</li>
          <li>urn:dnp:api:consent:v2 -- the second edition of an API contract</li>
          <li>urn:dnp:dataset:connectivity-index:2026-06-30 -- a dataset edition published on a recurring cycle</li>
        </ul>
      </section>
    </section>

    <section anchor="assignment" numbered="true">
      <name>Assignment</name>

      <section anchor="authority" numbered="true">
        <name>Assignment Authority</name>
        <t>Assignment within this namespace is closed. Names are assigned
        solely by PDA, or by an entity acting under a written instrument of
        delegation issued by PDA. Assignment is not open to application by
        third parties and there is no procedure by which an external party
        may request that a name be assigned to a resource of its own.</t>
        <t>Delegation is contemplated because instruments within scope may be
        issued by federal or provincial entities under PDA's coordinating
        mandate. A delegation instrument specifies the classes and the
        local-id ranges within which the delegate may assign, and binds the
        delegate to the persistence commitment in
        <xref target="persistence"/>. Delegations in force are listed in the
        Register. A delegation may be withdrawn; withdrawal has no effect on
        names already assigned under it, which remain valid and remain the
        responsibility of PDA.</t>
      </section>

      <section anchor="uniqueness" numbered="true">
        <name>Uniqueness</name>
        <t>Uniqueness is enforced by construction. PDA maintains a single
        authoritative Register of all assigned names. A name is brought into
        existence only by an entry in the Register, and the Register rejects
        any entry whose assigned-name is URN-equivalent, under
        <xref target="equivalence"/>, to an existing entry. Delegated
        assignment operates against the same Register and within
        non-overlapping allocations, so a delegate cannot create a collision
        with PDA or with another delegate.</t>
        <t>The Register records, for each name: the assigned-name; the
        instrument or edition identified; the date of assignment; the
        assigning entity; the current status; the current authoritative
        location or locations of the identified resource; a cryptographic
        digest of each edition-level resource as published; titles and
        descriptive metadata in English and Urdu; and any equivalent
        identifiers in other identifier systems.</t>
      </section>

      <section anchor="persistence" numbered="true">
        <name>Persistence and Non-Reassignment</name>
        <t>A name assigned within this namespace <bcp14>MUST NOT</bcp14> be
        reassigned to a different resource, and <bcp14>MUST NOT</bcp14> be
        withdrawn or deleted, under any circumstance. This holds where the
        identified instrument is superseded, repealed, withdrawn from effect,
        or found to have been issued in error; where the organisational unit
        that issued it is abolished or merged; and where the instrument is no
        longer published. In each case the fact is recorded as a status
        change in the Register and the name continues to identify what it has
        always identified.</t>
        <t>An error in an assignment is corrected by recording the error in
        the Register and, if necessary, assigning a new name. It is never
        corrected by reusing the erroneous name.</t>
      </section>

      <section anchor="continuity" numbered="true">
        <name>Institutional Continuity</name>
        <t>Section 5.1 of <xref target="RFC8141"/> asks that it be clear how
        a namespace remains viable if the assigning organisation can no
        longer maintain it.</t>
        <t>PDA is a body created by primary legislation rather than by
        administrative order, and its dissolution or reconstitution would
        require an act of the legislature. Pakistani legislative practice on
        the reconstitution of statutory bodies provides for the devolution of
        the functions, assets and records of a dissolved body upon a
        successor or upon the Division concerned. Stewardship of this
        namespace and of the Register is a function within the meaning of
        that practice, and would devolve accordingly.</t>
        <t>PDA additionally undertakes the following, which do not depend on
        PDA's continued existence:</t>
        <ul>
          <li>The Register is published in full as a machine-readable open
          dataset, refreshed on a regular cycle, so that a complete copy
          exists outside PDA's own systems at all times.</li>
          <li>PDA deposits the Register and the published corpus with
          Pakistan's national depository institutions and offers the same
          deposit to international web-archiving initiatives, so that the
          identifier-to-resource binding survives independently of PDA's
          infrastructure.</li>
          <li>If stewardship is transferred, PDA or its successor will submit
          a revised registration template under Section 6.2 of
          <xref target="RFC8141"/> recording the change. Transfer of
          stewardship does not affect the validity of names already
          assigned.</li>
        </ul>
      </section>
    </section>

    <section anchor="security" numbered="true">
      <name>Security and Privacy</name>

      <section anchor="privacy" numbered="true">
        <name>Absence of Personal Data</name>
        <t>Names in this namespace are assigned only to published
        institutional instruments. A name <bcp14>MUST NOT</bcp14> be assigned
        to a natural person, to an identifier of a natural person, to an
        individual transaction or record, or to any resource whose
        representation contains personal data.</t>
        <t>This constraint is stated normatively because PDA's statutory
        mandate includes national digital identity and data exchange
        infrastructure, and because the persistence properties that make URNs
        attractive for institutional documents make them actively harmful for
        identifiers of people. A URN cannot be revoked, and the
        non-reassignment commitment in <xref target="persistence"/> is
        incompatible with any right of erasure. Extending this namespace to
        cover personal or transactional data would require a new namespace
        registration with a materially different persistence model, and PDA
        does not propose one.</t>
        <t>The Register records the names of officers only in their
        institutional capacity, as the approving authority for an instrument,
        which is information already disclosed on the face of the published
        instrument.</t>
      </section>

      <section anchor="comparison" numbered="true">
        <name>Comparison and Confusion</name>
        <t>The case-insensitivity rule in <xref target="equivalence"/>
        introduces the general risks discussed in
        <xref target="RFC6943"/> for identifiers compared under case folding.
        Those risks are bounded here: the NSS is restricted to ASCII letters,
        digits, hyphen and full stop, so ASCII case folding is
        locale-independent, involves no expansion or contraction of
        characters, and admits no Unicode confusables. The Turkish dotless-i
        problem does not arise because folding is defined over the ASCII
        range only. Implementations <bcp14>MUST</bcp14> perform case folding
        over the ASCII range only and <bcp14>MUST NOT</bcp14> apply
        locale-sensitive case mapping.</t>
        <t>A false positive in comparison could cause a system to treat a
        conformance assertion against one instrument as an assertion against
        another. Because the identified resources are public and the Register
        is published, such an error is detectable by inspection.</t>
        <t>Because the work-level and edition-level forms of a name are
        similar in appearance but identify different resources
        (<xref target="editions"/>), an implementation that truncates or
        elides the edition field will silently substitute a work-level
        citation for an edition-level one. Where the citation appears in a
        conformance or contractual context this changes its meaning.
        Implementations <bcp14>MUST NOT</bcp14> truncate names, and
        applications that display names <bcp14>SHOULD</bcp14> display them in
        full, consistent with Section 4.4 of <xref target="RFC8141"/>.</t>
      </section>

      <section anchor="authenticity" numbered="true">
        <name>Authenticity and Spoofing</name>
        <t>A name in this namespace asserts nothing about the authenticity of
        any document it may be attached to. A third party can place the
        string "urn:dnp:standard:..." on an unauthorised document as easily
        as it can place any other string. The Register, retrieved over an
        authenticated channel, is the sole authority for what a name
        identifies; the cryptographic digests it records for edition-level
        resources allow a retrieved document to be checked against the
        published text.</t>
        <t>Consistent with Section 8 of <xref target="RFC8141"/>, the
        information in this registration is a declaration and should be
        treated as advisory.</t>
      </section>

      <section anchor="resolver-privacy" numbered="true">
        <name>Resolver Operation</name>
        <t>Where PDA operates a resolution service
        (<xref target="resolution"/>), queries to that service reveal to PDA
        which instruments a given client is interested in, and, absent
        transport security, reveal the same to network observers. Because
        the corpus includes policy and regulatory instruments, that interest
        may be sensitive; a pattern of queries could indicate the direction
        of an entity's compliance work or of a researcher's enquiry.</t>
        <t>Accordingly the PDA resolver <bcp14>MUST</bcp14> be offered over
        HTTPS, <bcp14>MUST NOT</bcp14> require authentication, and
        <bcp14>MUST NOT</bcp14> require or set cookies. PDA retains resolver
        request logs only in aggregate form and only for capacity planning,
        and does not disclose individual query records.</t>
        <t>Directory harvesting is not a concern for this namespace: the
        Register is published in full and complete enumeration of the
        namespace is an intended feature rather than an attack.</t>
      </section>
    </section>

    <section anchor="interop" numbered="true">
      <name>Interoperability</name>

      <t>PDA is aware of the following potential sources of confusion and
      addresses each here rather than leaving it to be discovered later.</t>

      <t><strong>The string "DNP".</strong> "DNP" is used as a corporate
      brand by at least one substantial commercial enterprise unconnected
      with Pakistan, which holds trademark registrations in that string in
      several jurisdictions and operates a brand top-level domain under it.
      "DNP" is also an established abbreviation in chemistry and in
      professional sport. PDA claims no association with any of these, and
      the registration of this NID neither asserts nor implies any right in
      the string outside the URN namespace registry. PDA has selected the
      string because it is the statutory short form of Digital Nation
      Pakistan, the programme established by the Act of the same name, and
      not for any associative value. PDA notes that a URN NID and a
      trademark occupy different registries with different scopes, that no
      resource identified in this namespace is a commercial good or service,
      and that Section 5.1 of <xref target="RFC8141"/> leaves disputes over
      strings to the parties concerned. PDA will engage in good faith with
      any objection raised during Expert Review.</t>

      <t><strong>Legal norms.</strong> The boundary with the "lex" namespace
      <xref target="RFC9676"/> is set out in <xref target="scope-limits"/>.
      Instruments in this namespace frequently cite Pakistani legislation;
      such citations use "lex" or the Gazette reference, not this
      namespace. An instrument issued by PDA under a statutory power is
      identified here as a directive; the statutory power itself is
      not.</t>

      <t><strong>Bibliographic identifiers.</strong> Pakistan has no
      registered National Bibliography Number sub-namespace under
      <xref target="RFC8458"/> at the time of writing. Should the national
      library register one and assign numbers to instruments in this corpus,
      the resulting names would coexist with names in this namespace and be
      recorded as equivalences in the Register. The same applies to Digital
      Object Identifiers, which PDA assigns to some publications through a
      DOI registration agency.</t>

      <t><strong>Internal document codes.</strong> PDA's internal document
      nomenclature codes appear within local-id in transformed form
      (<xref target="localid"/>). Those codes exist and circulate outside
      the URN context, and readers may encounter a code in isolation. A bare
      code is not a URN and <bcp14>MUST NOT</bcp14> be treated as one; the
      transformation from code to local-id is defined in the PDA
      specification referenced in the Documentation entry of
      <xref target="template"/>. The transformation is not in general
      reversible by inspection and implementations
      <bcp14>MUST NOT</bcp14> attempt to reverse it algorithmically.</t>

      <t><strong>Character handling.</strong> Because names never contain
      percent-encoded octets or non-ASCII characters
      (<xref target="abnf"/>), the encoding pitfalls that arise when
      pre-existing identifier systems are mapped into URN syntax do not
      arise here.</t>

      <t><strong>Protocol slots.</strong> Consistent with Section 4.1 of
      <xref target="RFC8141"/>, a name in this namespace is not a locator
      and <bcp14>SHOULD NOT</bcp14> be placed in a URI protocol slot whose
      defined semantics require dereferencing to a representation. It is
      appropriate in citation fields, metadata records, conformance
      declarations and provenance assertions.</t>
    </section>

    <section anchor="resolution" numbered="true">
      <name>Resolution</name>

      <t>Resolution is intended. PDA operates and undertakes to continue to
      operate a resolution service for names in this namespace.</t>

      <t>The service is offered over HTTPS at the endpoint
      https://urn.dnp.gov.pk/, operated by PDA under a Government of Pakistan
      domain. A client resolves a name by requesting the assigned-name as a
      path component of that endpoint, for example
      https://urn.dnp.gov.pk/urn:dnp:standard:dnp-x.001:v2. The endpoint is
      also recorded in the PDA specification referenced in the Documentation
      entry of <xref target="template"/>; should it ever change, the
      specification and this registration are revised, and names already
      assigned are unaffected.</t>

      <t>Resolution behaviour follows the work/edition distinction of
      <xref target="editions"/>:</t>
      <ul>
        <li>A work-level name resolves to the current authoritative edition
        of the instrument where one is in force, and otherwise to a record
        describing the instrument and its editions.</li>
        <li>An edition-level name resolves to that fixed edition, and
        continues to do so after it has been superseded. A superseded edition
        remains retrievable and is marked as superseded, with a reference to
        the edition that superseded it. PDA does not remove superseded
        editions from publication.</li>
      </ul>

      <t>A client that requests a representation of the identified resource
      receives it, or a redirection to its current location. A client that
      requests metadata, by content negotiation, receives the Register record
      for the name, including status, provenance, digests and equivalent
      identifiers. Resolution of a syntactically valid name that has not been
      assigned is distinguishable from resolution of a name that has been
      assigned to an instrument that is no longer in force; the two are
      different conditions and are reported differently.</t>

      <t>Resolution is a convenience and is not constitutive. A name remains
      valid, and continues to identify what the Register says it identifies,
      irrespective of whether any resolver is reachable, and irrespective of
      whether the identified resource is currently retrievable.</t>

      <t>PDA does not at present operate a registration process for
      third-party publicly advertised resolution services for this namespace,
      and does not at present recommend any resolver other than its own.
      Should PDA establish such a process, the requirements for being
      publicly advertised will be published alongside the specification
      referenced in the Documentation entry, and this registration will be
      revised. Handling of r-components is specified in
      <xref target="components"/>: PDA defines none, and its resolver ignores
      any that are presented.</t>
    </section>

    <section anchor="additional" numbered="true">
      <name>Additional Information</name>
      <t>The Digital Nation Pakistan Act, 2025 <xref target="DNPACT"/>
      establishes PDA and sets out its functions, including the specification
      of national digital standards and the coordination of digitalisation
      across government. The Act is the source of PDA's authority to issue
      the instruments identified in this namespace and of the institutional
      continuity described in <xref target="continuity"/>.</t>
      <t>Registrations by national government bodies in this registry
      include those of the Federal Chancellery of the Republic of Austria and
      of New Zealand <xref target="RFC4350"/>, and by national memory
      institutions including the National Archives of Finland. This
      registration follows the same pattern: a national public authority
      seeking durable identification of a defined corpus of official
      material, without any claim to a country-code-derived namespace. PDA
      notes that Section 5.1 of <xref target="RFC8141"/> reserves strings of
      the form ALPHA ALPHA "-" for possible future country-code-based
      registration; this registration does not use, anticipate or depend on
      any such reservation.</t>
    </section>

    <section anchor="iana" numbered="true">
      <name>IANA Considerations</name>
      <t>This document requests that IANA register the formal URN Namespace
      Identifier "dnp" in the "Formal URN Namespaces" registry, using the
      registration template in <xref target="template"/>, in accordance with
      Section 6.2 of <xref target="RFC8141"/>.</t>
      <t>This document makes no other request of IANA.</t>
    </section>

    <section anchor="seccons" numbered="true">
      <name>Security Considerations</name>
      <t>Security and privacy considerations for this namespace are set out
      in <xref target="security"/>, in accordance with Section 6.4.4 of
      <xref target="RFC8141"/>. General security considerations for URN
      namespaces are given in Section 8 of <xref target="RFC8141"/>.</t>
    </section>

  </middle>

  <back>
    <references>
        <name>Normative References</name>

        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner"/>
            <date year="1997" month="March"/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>

        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee"/>
            <author initials="R." surname="Fielding" fullname="R. Fielding"/>
            <author initials="L." surname="Masinter" fullname="L. Masinter"/>
            <date year="2005" month="January"/>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>

        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author initials="D." surname="Crocker" fullname="D. Crocker" role="editor"/>
            <author initials="P." surname="Overell" fullname="P. Overell"/>
            <date year="2008" month="January"/>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>

        <reference anchor="RFC8141" target="https://www.rfc-editor.org/info/rfc8141">
          <front>
            <title>Uniform Resource Names (URNs)</title>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre"/>
            <author initials="J." surname="Klensin" fullname="J. Klensin"/>
            <date year="2017" month="April"/>
          </front>
          <seriesInfo name="RFC" value="8141"/>
          <seriesInfo name="DOI" value="10.17487/RFC8141"/>
        </reference>

        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba"/>
            <date year="2017" month="May"/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>

      <references>
        <name>Informative References</name>

        <reference anchor="RFC4350" target="https://www.rfc-editor.org/info/rfc4350">
          <front>
            <title>A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government</title>
            <author initials="F." surname="Hendrikx" fullname="F. Hendrikx"/>
            <author initials="C." surname="Wallis" fullname="C. Wallis"/>
            <date year="2006" month="February"/>
          </front>
          <seriesInfo name="RFC" value="4350"/>
          <seriesInfo name="DOI" value="10.17487/RFC4350"/>
        </reference>

        <reference anchor="RFC6943" target="https://www.rfc-editor.org/info/rfc6943">
          <front>
            <title>Issues in Identifier Comparison for Security Purposes</title>
            <author initials="D." surname="Thaler" fullname="D. Thaler" role="editor"/>
            <date year="2013" month="May"/>
          </front>
          <seriesInfo name="RFC" value="6943"/>
          <seriesInfo name="DOI" value="10.17487/RFC6943"/>
        </reference>

        <reference anchor="RFC8458" target="https://www.rfc-editor.org/info/rfc8458">
          <front>
            <title>Using National Bibliography Numbers as Uniform Resource Names</title>
            <author initials="J." surname="Hakala" fullname="J. Hakala"/>
            <date year="2018" month="October"/>
          </front>
          <seriesInfo name="RFC" value="8458"/>
          <seriesInfo name="DOI" value="10.17487/RFC8458"/>
        </reference>

        <reference anchor="RFC9676" target="https://www.rfc-editor.org/info/rfc9676">
          <front>
            <title>A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)</title>
            <author initials="P.L." surname="Spinosa" fullname="P.L. Spinosa"/>
            <author initials="E." surname="Francesconi" fullname="E. Francesconi"/>
            <author initials="C." surname="Lupo" fullname="C. Lupo"/>
            <date year="2025" month="May"/>
          </front>
          <seriesInfo name="RFC" value="9676"/>
          <seriesInfo name="DOI" value="10.17487/RFC9676"/>
        </reference>

        <reference anchor="DNPACT" target="https://na.gov.pk/">
          <front>
            <title>The Digital Nation Pakistan Act, 2025 (Act No. IV of 2025)</title>
            <author>
              <organization>Government of Pakistan</organization>
            </author>
            <date year="2025" month="January"/>
          </front>
          <refcontent>The Gazette of Pakistan, Extraordinary, Part I, 29 January 2025</refcontent>
        </reference>
    </references>

  </back>
</rfc>
