Re: URN registration - Email found in subject

[Ted Hardie <[e-mail]>]

Hi Will,

On Mon, Mar 7, 2011 at 9:05 AM, DTG Registration
<[e-mail]> wrote:
> Hello,
>
> No, "metadata" is a textual example of what will follow urn:dtg:...
>
Sorry that I haven't made myself clear.  The literal string "metadata"
does not match your ABNF, and I was hoping you would provide an actual
example.  I inferred that it was a different way of saying "<assigned
number>:<FQDN>" with "cs" as the assogmed string.  If "metadata" is a
textual example, then your ABNF is wrong, as it contains neithr the
assigned number or FQDN you say will be there.

> Does our urn require an assigned number? Does this come from ietf? I don't think we require a number, apologies for the confusion.
>
Your registration form currently implies your organization assigns a
unique number.  If you are guaranteeing uniqueness in some other way,
how need to be made clear.  The IETF would not assign these resources
numbers.

> Regarding Community Considerations, I will review the information provided and provide an update.
>
> Many thanks,
>
> Will Godfrey
>

regards,

Ted Hardie
>
>
>
>
> -----Original Message-----
> From: Ted Hardie [mailto:[e-mail]]
> Sent: 02 March 2011 17:52
> To: DTG Registration
> Cc: [e-mail]
> Subject: Re: URN registration - Email found in subject
>
> On Wed, Mar 2, 2011 at 9:31 AM, DTG Registration
> <[e-mail]> wrote:
>> Hello,
>>
>> An example of a completed URN is:
>>
>> urn:dtg:metadata:cs
>>
>
> I'm sorry, but does "metadata" mean the tuple of assigned number and fqdn?
>
>> Do the IETF have a preferred mechanism to guarantee uniqueness?  Forbidding reassignment of the assigned number would not be problematic for our use of the urn.
>>
> There is no preferred method, but forbidding reassignment of the
> string/number you assign is a relatively easy way to ensure it.
>
>> Which community are you referring to?
>>
>
> See http://tools.ietf.org/html/rfc3406 for the registration
> requirements; section 4.3 has the text on community considerations.
> You may also want to look a recent registration, like
> http://tools.ietf.org/html/rfc5165 for insight.
>
> regards,
>
> Ted Hardie
>
>> Many thanks,
>>
>> Will Godfrey
>>
>>
>>
>>
>> -----Original Message-----
>> From: Ted Hardie [mailto:[e-mail]]
>> Sent: 02 March 2011 17:13
>> To: DTG Registration
>> Cc: [e-mail]
>> Subject: Re: URN registration - Email found in subject
>>
>> Howdy,
>>
>> The text of this NID registration seems to rely on fully qualified
>> domain names never being reasssigned ("that the FQDN is never
>> reassigned") to guarantee uniqueness.  This is, of course, not a
>> property guaranteed by the DNS.
>>
>> The structure:
>>
>>  URN:<assigned number>:<FQDN>:<assigned string>
>>
>> hints, though, that the actual guarantee of uniqueness might be based
>> on a tuple of the first assigned string and the fqdn.  This might
>> work, though it would be simpler to forbid reassignment of the
>> assigned number.
>>
>> Can you clarify which strategy is intended here?  An example of a
>> completed URN would also be helpful.
>>
>> Lastly, the registration template should contain a "Community
>> Considerations" section, which is missing here.
>>
>> regards,
>>
>> Ted Hardie
>>
>> On Wed, Mar 2, 2011 at 8:02 AM, DTG Registration
>> <[e-mail]> wrote:
>>> Namespace ID: To be assigned
>>>
>>> Registration Information:
>>> Registration version number: 1
>>> Registration date: 2011-02-24
>>>
>>> Declared registrant of the namespace:
>>> Registering organization
>>>        Name: Digital Television Group
>>>        Address: 1 Nine Elms Lane, London, SW8 5NQ UK
>>> Designated contact person
>>>        Name: Ali Teffahi
>>>        Coordinates: [e-mail]
>>>
>>> Declaration of syntactic structure:
>>>        The identifier structure is as follows:
>>>        URN:<assigned number>:<FQDN>:<assigned string>
>>>        URN:dtg
>>>
>>> Relevant ancillary documentation:
>>>        Definition of domain names, found in:
>>>        P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
>>> SPECIFICATION",
>>>        RFC 1035, November 1987.
>>>
>>> Identifier uniqueness considerations:
>>>        Uniqueness is guaranteed as long as the assigned string is never
>>> reassigned for a given FQDN, and that the FQDN is never reassigned.
>>>
>>> Identifier persistence considerations:
>>>        Persistence of identifiers is dependent upon suitable delegation
>>> of resolution at the level of "FQDN"s, and persistence of FQDN
>>> assignment.
>>>
>>> Process of identifier assignment:
>>>        Assignment of these URNs is delegated to individual domain name
>>> holders (for FQDNs).  The holder of the FQDN registration is required to
>>> maintain an     entry (or delegate it) in the DDDS. Within each of these
>>> delegated name partitions, the string may be assigned per local
>>> requirements.
>>>
>>> Process for identifier resolution:
>>>        Domain name holders are responsible for operating or delegating
>>> resolution servers for the FQDN in which they have assigned URNs.
>>>
>>> Rules for Lexical Equivalence:
>>>        FQDNs are case-insensitive.  Thus, the portion of the URN
>>>        URN:dtg
>>>        is case-insensitive for matches.  The remainder of the
>>> identifier must be considered case-insensitive also.
>>>
>>> Conformance with URN Syntax:
>>>        No special considerations.
>>>
>>> Validation mechanism:
>>>        None specified.
>>>
>>> Scope:
>>>        Global.
>>>
>>>
>>> The information in this email and any attachments is confidential, may be subject to copyright and is intended solely for the addressee (s). Access to this email by anyone else is unauthorised. If you are not the intended recipient, please notify the sender and delete this e-mail.  In this case, please note that copying, disseminating or taking any action in relation to the contents of this e-mail is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Digital TV Group. Digital TV Group cannot ensure that emails are virus-free and therefore accepts no liability for viruses that might be transferred by this email or any attachment.
>>>
>>>
>>>
>>>
>>>
>>
>>
>> The information in this email and any attachments is confidential, may be subject to copyright and is intended solely for the addressee (s). Access to this email by anyone else is unauthorised. If you are not the intended recipient, please notify the sender and delete this e-mail.  In this case, please note that copying, disseminating or taking any action in relation to the contents of this e-mail is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Digital TV Group. Digital TV Group cannot ensure that emails are virus-free and therefore accepts no liability for viruses that might be transferred by this email or any attachment.
>>
>>
>>
>>
>>
>
>
> The information in this email and any attachments is confidential, may be subject to copyright and is intended solely for the addressee (s). Access to this email by anyone else is unauthorised. If you are not the intended recipient, please notify the sender and delete this e-mail.  In this case, please note that copying, disseminating or taking any action in relation to the contents of this e-mail is strictly prohibited. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Digital TV Group. Digital TV Group cannot ensure that emails are virus-free and therefore accepts no liability for viruses that might be transferred by this email or any attachment.
>
>
>
>
>