Re: Application for a formal URN NID

[Ted Hardie <[e-mail]>]

Maybe nits:

Section 2.1 gives this as the requested Namespace ID:

"Professional-Plug-in"

But your example in Section 3 says:

URN:schemas-Professional-Plug-in:P2:ClipMetadata:v2.0

Is it the intent to have "schemas-" present or not?

In general, this seems like a pretty long NID, with or without
the "schemas" prepended. 

Maybe not nits:

This seems to be related to the work of SMPTE.  Are you
aware of draft-edwards-urn-smpte-01.txt?  Is there a reason
that this would not fall under it, if the SMPTE NID is approved
(it is in Last Call now).

		regards,
			Ted



At 7:44 AM -0400 5/22/07, John Wus wrote:
>Content-Type: text/plain
>X-MIME-Autoconverted: from 8bit to quoted-printable by
>	atvl10.pav.research.panasonic.com id l4MBeIU5019114
>
>Dear All,
>
>As per RFC 3406, I am requesting a two-week review for a formal URN namespace request.  I would like to request a URN Namespace for "Professional-Plug-in".  I have attached an I-D application for our formal URN NID request.  This Internet Draft has been published and is available at:
>
>http://www.ietf.org/internet-drafts/draft-ohtaka-urn-professional-plug-in-00.txt
>
>Thank you in advance.
>
>Best Regards,
>John Wus
>
>--
>
>+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
>|                                                           |
>|   John Wus, PhD.                                          |          
>|   Principal Member Engineering Staff                      |
>|   Panasonic AVC Engineering Promotion Center of America   |
>|   500 Dearborn Circle, Suite 100                          |
>|   Mount Laurel, New Jersey 08054                          |
>|   Phone: [phone] ext. 140                            |
>|   Fax:   [phone]                                     |
>|   email: [e-mail]                        |
>|                                                           |
>+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
>
>
>Internet Draft                                                  H.Ohtaka
>Expires: November 2007                                            J. Wus
>                                                             14 May 2007
>
>     A Uniform Resource Name (URN) Namespace for Professional-Plug-in
>              draft-ohtaka-urn-professional-plug-in-00.txt
>
>Status of this Memo
>
>   By submitting this Internet-Draft, each author represents that any
>   applicable patent or other IPR claims of which he or she is aware
>   have been or will be disclosed, and any of which he or she becomes
>   aware will be disclosed, in accordance with Section 6 of BCP 79.
>
>   Internet-Drafts are working documents of the Internet Engineering
>   Task Force (IETF), its areas, and its working groups.  Note that
>   other groups may also distribute working documents as Internet-
>   Drafts.
>
>   Internet-Drafts are draft documents valid for a maximum of six months
>   and may be updated, replaced, or obsoleted by other documents at any
>   time.  It is inappropriate to use Internet-Drafts as reference
>   material or to cite them other than as "work in progress."
>
>   The list of current Internet-Drafts can be accessed at
>   http://www.ietf.org/1id-abstracts.txt.
>
>   The list of Internet-Draft Shadow Directories can be accessed at
>   http://www.ietf.org/shadow.html.
>
>   This Internet-Draft will expire on November 14, 2007.
>
>Copyright Notice
>
>   Copyright (C) The Internet Society (2007).  All Rights Reserved.
>
>Abstract
>
>   This document describes a Uniform Resource Name (URN) namespace for
>   naming persistent resources as eXtensible Markup Language (XML)
>   Schemas in Professional-Plug-in system.
>
>Ohtaka, et al.             Expires November 14, 2007            [Page 1]
>
>Internet-Draft      URN Namespace for Professional Plug-in      May 2007
>
>Table of Contents
>
>   1. Introduction...................................................2
>   2. Namespace Definition Template..................................2
>      2.1. Namespace ID:.............................................2
>      2.2. Registration Information:.................................2
>      2.3. Declared registrant of the namespace:.....................2
>      2.4. Declaration of structure:.................................3
>      2.5. Relevant ancillary documentation:.........................3
>      2.6. Identifier uniqueness considerations:.....................3
>      2.7. Identifier persistence considerations:....................3
>      2.8. Process of identifier assignment:.........................3
>      2.9. Process for identifier resolution:........................3
>      2.10. Rules for Lexical Equivalence:...........................3
>      2.11. Conformance with URN Syntax:.............................4
>      2.12. Validation mechanism:....................................4
>      2.13. Scope....................................................4
>   3. Formal Syntax..................................................4
>   4. Security Considerations........................................4
>   5. Namespace Considerations.......................................4
>   6. Community Considerations.......................................5
>   7. IANA Considerations............................................5
>   8. Normative References...........................................5
>   9. Author's Addresses.............................................5
>  10. Copyright Statement............................................5
>  11. Intellectual Property..........................................5
>  12. Acknowledgment.................................................5
>  
>1.  Introduction
>
>   Professional-Plug-in is a system which defines a solid-state storage
>   media and a variety of multimedia contents stored on this storage media.
>   The Professional-Plug-in is applicable for content acquisition systems,
>   editing systems and servers as well as for transfer of content files.
>   In order to assure interoperability among different vendors,
>   specifications that define a video, audio essence and associated
>   metadata have been established. The metadata contains information about
>   the structure or parameters of the video, audio essences and also contains
>   additional information describing the essences. The metadata is
>   expressed with an XML specified by an XML schema. Therefore,
>   a Uniform Resource Name (URN) specified in this document is applied to
>   assign a persistent resource for the namespace to identify each XML schema.
>
>2.  Specification Template
>
>   This namespace specification is for a formal namespace.
>
>2.1 Namespace ID:
>
>   "Professional-Plug-in"
>
>2.2 Registration Information:
>
>   Version: 1.0
>   Date: 14 May 2007
>
>2.3 Declared registrant of the namespace:
>
>   Name:           Hideki Ohtaka
>   Organization    Matsushita Electric Industrial Co., Ltd.
>   Address:        2-15 Matsuba-cho, Kadoma City, Osaka 571-8503, Japan           
>   Phone:          [phone]
>   Email:          [e-mail]
>
>Ohtaka, et al.             Expires November 14, 2007            [Page 2]
>
>Internet-Draft      URN Namespace for Professional Plug-in      May 2007
>
>2.4 Declaration of structure:
>
>   URN assigned for Professional-Plug-in has the following structure.
>
>   URN:schemas-Professional-Plug-in:NSS
>
>   The NSS shall comply with the following ABNF specification.
>
>   NSS             = SystemName ":" AssignedString ":" AssignedString ":" ----
>   SystemName      = ALPHA / DIGIT / other
>   AssignedString  = ALPHA / DIGIT / other
>   other           = "-" / "_" / "."
>   Note: Another character may not be the first character.
> 
>2.5 Relevant ancillary documentation:
>
>   Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation 04
>   February 2004
>
>   Namespaces in XML, W3C Recommendation, 14,January 1999
>
>   SMPTE RP 2002 Content Specification on Solid-State Media Card
>   - for DV/DV-based Essence : This document defines the XML schema specified
>   by the namespace using the requested NID.
>
>2.6 Identifier uniqueness considerations:
>
>   Developers who wish to define a new system name under this proposed NID
>   for their applications must ask the URN administrator (Matsushita Electric)
>   to assign a system name as NSS. The URN administrator confirms that the new
>   system name is unique against existing system names, and then assigns and
>   registers the new system name as NSS.
>
>2.7 Identifier persistence considerations:
>
>   Persistence of identifiers is dependent upon the persistence of the system
>   name assignment by the URN administrator.
>
>2.8 Process of identifier assignment:
>
>   Request for the assignment of a new system name including objectives of
>   the request must be sent to the URN administrator and the URN administrator
>   assigns the new system name as NSS.
>
>2.9 Process of identifier resolution:
>  
>   The URN administrator will maintain an index of assigned URNs
>   That index will map URNs to XML schema specifications in the Web page.
> 
>2.10 Rules for Lexical Equivalence:
> 
>   The entire URN is case-insensitive.
>
>Ohtaka, et al.             Expires November 14, 2007            [Page 3]
>
>Internet-Draft      URN Namespace for Professional Plug-in      May 2007
>
>2.11 Conformance with URN Syntax:
>
>   No special considerations.
>   URNs in this namespace conform to RFC 2141.
>
>2.12 Validation mechanism:
>
>   None specified.
>
>2.13 Scope:
>
>   Global
>
>   The following is an example of the URN.
>
>3.  Examples
>
>   URN:schemas-Professional-Plug-in:P2:ClipMetadata:v2.0
>
>   System name     = P2: Specifies the system
>   Assigned string = ClipMetadata: Specifies the type of metadata
>                                   ClipMetadata means the Metadata schema
>                                   related to a Clip 
>   Assigned string = v2.0: Specifies the version of this schema
>
>4.  Namespace Considerations
>
>4.1 URN assignment procedures:
>
>   Existing URNs are intended to be assigned as identifiers for particular
>   applications or particular systems. The purpose of these URNs and its
>   assignment procedure is clearly defined in each RFC document. Meanwhile,
>   this requested URN is intended to be used for a namespace to identify an
>   XML schema in Professional-Plug-in system so the metadata specified with
>   an XML schema is closely associated with its individual system and
>   applications. The existing URNs, however, do not provide any alternative
>   namespaces which represent the metadata in the Professional-Plug-in system.
>   Therefore, a new URN assignment is required and individual URNs shall be
>   assigned through the process of development of each XML schema. 
>
>4.2 URN resolution/delegation:
>
>   The resolution and delegation shall be determined through the process of
>   development of an XML schema for metadata.
>
>4.3 Type of resources to be identified:
>
>   Types of resources to be identified include an XML schema for metadata.
>
>5.  Community Considerations
>
>5.1 Open assignment and use of identifiers within the namespace:
>
>  Professional-Plug-in system can be applicable for content acquisition
>  systems, editing systems and so on. Therefore, any developers who wish to
>  define an XML schema depending on each application can apply for a URN
>  under the Professional-Plug-in namespace. The proposed URN shall be reviewed
>  among developers of the Professional-Plug-in system, and shall be assigned
>  and presented as a new URN under this namespace.
>     
>Ohtaka, et al.             Expires November 14, 2007            [Page 4]
>
>Internet-Draft      URN Namespace for Professional Plug-in      May 2007
>
>6.  Security Considerations
>
>   There are no additional security considerations other than those
>   normally associated with the use and resolution of URNs in general.
>
>7.  IANA Considerations
>
>   The IANA has registered formal URN namespace XXXX, to
>   Professional-Plug-in within the IANA registry of URN NIDs.
>
>8.  Normative References
>
>   [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
>
>9.  Author's Addresses
>
>   Hideki Ohtaka
>   Matsushita Electcic Industrial Co., Ltd.
>   2-15 Matsuba-cho, Kadoma City, Osaka 571-8503, Japan
>   Phone:  [phone]
>   Email:  [e-mail]
>
>   John Wus
>   Panasonic AVC Engineering Promotion Center of America
>   5000 Dearborn Circle
>   Suite 100
>   Mount Laurel, New Jersey 08054
>   Email: [e-mail]
>
>10.  Copyright Statement
>
>   Copyright (C) The IETF Trust (2007).
>
>   This document is subject to the rights, licenses and restrictions
>   contained in BCP 78, and except as set forth therein, the authors
>   retain all their rights.
>
>   This document and the information contained herein are provided on an
>   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
>   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
>   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
>   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>11. Intellectual Property
>
>   The IETF takes no position regarding the validity or scope of any
>   Intellectual Property Rights or other rights that might be claimed to
>   pertain to the implementation or use of the technology described in
>   this document or the extent to which any license under such rights
>   might or might not be available; nor does it represent that it has
>   made any independent effort to identify any such rights.  Information
>   on the procedures with respect to rights in RFC documents can be
>   found in BCP 78 and BCP 79.
>
>   Copies of IPR disclosures made to the IETF Secretariat and any
>   assurances of licenses to be made available, or the result of an
>   attempt made to obtain a general license or permission for the use of
>   such proprietary rights by implementers or users of this
>   specification can be obtained from the IETF on-line IPR repository at
>   http://www.ietf.org/ipr.
>
>   The IETF invites any interested party to bring to its attention any
>   copyrights, patents or patent applications, or other proprietary
>   rights that may cover technology that may be required to implement
>   this standard.  Please address the information to the IETF at
>   [e-mail].
>
>12. Acknowledgment
>   Funding for the RFC Editor function is provided by the IETF
>   Administrative Support Activity (IASA).
>
>Ohtaka, et al.             Expires November 14, 2007            [Page 5]
>