Subject: URN namespaces Submission for Ad-ID (www.ad-id.org)

From: Jarrett Wold <[email-masked]>
Date: Fri, 11 Mar 2016 09:32:56 -0500

Hello –

I am resubmitting a request for an URN on behalf of Ad-ID as an Internet
Draft.

Thank You

*Jarrett Wold *| *Ad-ID LLC*
Director of Technology & Platforms
646-708-8131

[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Fri, 11 Mar 2016 08:53:36 -0800

Hi Jarrett,

I've done a quick review and I have a couple of questions.  The document
states that AD-Id assigns the identifiers and guarantees uniqueness, but it
also notes that the initial section of the identifier is a company prefix.
Is the process of assignment distributed or centralizes?

The document notes that an ad-id can be validated using ad-id's web
services.  Does or will that interface presenting the urn:adid form or the
urn:adid;cuid form?  If you present an ad-id, does it return the resource
or present metadata about the resource?

As a nit, it is more common for the abnf to split out the canonical string
"urn:" and the definition of the nid (in this case adid).

regards,

Ted Hardie

---

From: Jarrett Wold <[email-masked]>
Date: Fri, 11 Mar 2016 12:34:02 -0500

Hi Ted –

Thanks for the feedback.  Please see my answers inline:

The document states that AD-Id assigns the identifiers and guarantees
uniqueness, but it also notes that the initial section of the identifier is
a company prefix.  Is the process of assignment distributed or centralizes?

A company Prefix created in Ad-ID also unique in our system.  These are
centralized in our system. Example: AAAA, ABCD, AB01, etc.

A company can choose to create a prefix or let the system select a prefix
at random.  If they choose to create a prefix, the system will determine if
it is available and issue it if it is.  Once the prefix is created, it’s
used to create the full Ad-ID codes.

Example:  Company created two prefixes (ABCD & AB99).  Codes will be
generated under both prefixes based on what the user selects

*ABCD*

ABCD0001100

ABCD0002100

*AB99*

AB990001100

AB990002100

A user can use our web services and request by either an adid or the cuid.
Both resources are present in the XML returned (xml elements) as well as
descriptive metadata about the resource.

Im not quite clear on this.  Would you mind elaborating?

Thanks again.

[email-masked]

*From:* Ted Hardie [mailto:[email-masked]]
*Sent:* Friday, March 11, 2016 11:54 AM
*To:* Jarrett Wold <[email-masked]>
*Cc:* [email-masked]
*Subject:* Re: URN namespaces Submission for Ad-ID (www.ad-id.org)

Hi Jarrett,

regards,

Ted Hardie

Hello –

Thank You

[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Fri, 11 Mar 2016 16:22:38 -0800

Hi Jarrett,

Some further comments in-line.

On Fri, Mar 11, 2016 at 9:34 AM, Jarrett Wold <[email-masked]> wrote:

> Just to confirm my understanding, Ad-ID always creates the full code
(prefix + subcode), the process of producing the sub-code is not delegated
to the holder of the prefix.  Is that correct?

> descriptive metadata about the resource.
I see. Is there any method to dereference the resource by adid?  That is,
to return the ad on presentation of the adid? (Note that this is not
required, but if there were such a method, it would be a welcome addition
to the document)

> Im not quite clear on this.  Would you mind elaborating?

It's just more common to say something like this:

 assigned-name = "urn" ":" NID ":" NSS

 Then follow up with the ABNF for the NID and name-space specific string.

regards,

Ted Hardie

---

From: Jarrett Wold <[email-masked]>
Date: Mon, 14 Mar 2016 10:29:00 -0400

Good Morning Ted –

Further clarifications:

*Sent:* Friday, March 11, 2016 7:23 PM

Hi Jarrett,

Hi Ted –

Ad-ID will system will always create the code.   We do offer several
different “code templates” for how the subcode is generated.  In each case,
we ensure the code is unique before the system generates the code.

Here is a link that defines the Ad-ID Structure and the multiple options we
offer.

http://www.ad-id.org/how-it-works/ad-id-structure

*ABCD*

ABCD0001100

ABCD0002100

*AB99*

AB990001100

AB990002100

I’m not quite sure what you mean by this.  Are you asking about other
methods to retrieve data by presence of an Ad-ID?  We are working on a few
company initiatives to have Ad-IDs embedded in digital slate (MXF) files
and XMP.  In these case, both the Ad-ID and MetaData would be present.

Thanks again.

I can make this update.

regards,

Ted Hardie

[email-masked]

Hi Jarrett,

regards,

Ted Hardie

Hello –

Thank You

[email-masked]

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 14 Mar 2016 22:17:15 -0400

> I am resubmitting a request for an URN on behalf of Ad-ID as an Internet

You still haven't filed the document at
https://datatracker.ietf.org/submit/ Only when the document is filed is
it definitively recorded what is *in* the document.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 14 Mar 2016 22:44:11 -0400

Here are a bunch of comments on draft-adid-urn-00.  Overall the concept
seems fine, but the document needs cleaning up.

The title contains "Adverting".  Have you run the draft through a
spelling checker?

      The following is an example of an Ad-ID Identifier in its
      canonical representation:

             ABCD0001000

      The canonical URN representation of the same Ad-ID Identifier is:

         urn:adid:ABCD0001000
         urn:adid:ABCD0001000H

      The 32-bit unique representation of the Ad-ID is:

         urn:adid:cuid:36faeaba

This example is difficult to follow.  The first item is
straightforward, as it is an 11 character string.  But the next item
isn't clear:  by definition, a "canonical" representation is one
representation chosen from among many.  You can say that both

         urn:adid:ABCD0001000
         urn:adid:ABCD0001000H

are URN representations of the Ad-ID identifier, but only one of them
can be canonical.  Also, it would be helpful if you explained why both
URNs correspond to ABCD0001000, or at least provide a reference to
some description which will explain it.

But, reading http://www.ad-id.org/how-it-works/ad-id-structure, it
seems that ABCD0001000H is not the *same* Ad-ID as ABCD0001000, but
rather the Ad-ID for the corresponding High Definition version of the
asset.  You need to clarify this so that the example is not
misleading.

It is not clear how the further "32-bit unique representation"
corresponds to the preceding three representations.  It's reasonably
clear what "32-bit" means as the URN contains a sequence of 8 hex
digits, but it's completely unclear what is "unique" about it.

Remember, this is the introduction, which should be readable by people
who don't already understand the technology, including people who
don't already understand Ad-IDs in all their forms.

There's some general trouble about the indentation of text.  For
instance, it seems that "The identifier structure is as follows:"
should be 4 spaces to the left, "Non alphanumeric ("special")
characters and spaces are not valid within an Ad-ID." should have a
blank like above it and be moved 3 spaces to the left, and "A
Canonical Full Ad-ID ..." should be moved 1 space to the left.

This text has some redundancy that should be removed:

          A Canonical Full Ad-ID Identifier shall conform to the syntax
          specified below using ABNF (as specified in IETF RFC 5234):
          The URN representation URN-ADID of an Ad-ID Identifier
          conforms to the syntax (expressed using ABNF (as specified in
          [RFC5234]):

The production

          adid_prefix = (ALPHA / %x30-39) 4*alphanum
               ; first character not zero

is incorrect on two counts:  As written, the first character can be
zero (which ix %x30).  The strings generated are 5 characters.  What
you want is

          adid_prefix = (ALPHA / %x31-39) 3*alphanum
               ; first character not zero

The instances of ALPHA and DIGIT might be intended to be "alpha" and
"digit".  Or do you mean to reference the productions ALPHA and DIGIT
in RFC 5234?  If so, you should eliminate the productions for "alpha"
and "digit" in the draft.

The BNF does not show how the "urn:adid:cuid" URNs are generated.  As
the BNF now stands, those examples are invalid.

      Ad-ID URNs are resolved via URN resolvers run under Ad-ID's
      responsibility.

It would be helpful here to provide a pointer to the documentation for
the resolvers.

      The validity of an URN-ADID can be checked using Ad-ID's web
      services.

Ditto.

Dale

---

From: Jarrett Wold <[email-masked]>
Date: Tue, 15 Mar 2016 15:05:14 -0400

Thanks Dale -
I will review and get back to you soon. I'll get this submitted as an
Internet Draft as well.

I appreciate the feedback.
Jarrett

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]]
Sent: Monday, March 14, 2016 10:44 PM
To: Jarrett Wold <[email-masked]>
Cc: [email-masked]
Subject: Comments on draft-adid-urn-00

The title contains "Adverting".  Have you run the draft through a spelling
checker?

             ABCD0001000

         urn:adid:ABCD0001000
         urn:adid:ABCD0001000H

         urn:adid:cuid:36faeaba

This example is difficult to follow.  The first item is straightforward,
as it is an 11 character string.  But the next item isn't clear:  by
definition, a "canonical" representation is one representation chosen from
among many.  You can say that both

         urn:adid:ABCD0001000
         urn:adid:ABCD0001000H

are URN representations of the Ad-ID identifier, but only one of them can
be canonical.  Also, it would be helpful if you explained why both URNs
correspond to ABCD0001000, or at least provide a reference to some
description which will explain it.

But, reading http://www.ad-id.org/how-it-works/ad-id-structure, it seems
that ABCD0001000H is not the *same* Ad-ID as ABCD0001000, but rather the
Ad-ID for the corresponding High Definition version of the asset.  You
need to clarify this so that the example is not misleading.

It is not clear how the further "32-bit unique representation"
corresponds to the preceding three representations.  It's reasonably clear
what "32-bit" means as the URN contains a sequence of 8 hex digits, but
it's completely unclear what is "unique" about it.

Remember, this is the introduction, which should be readable by people who
don't already understand the technology, including people who don't
already understand Ad-IDs in all their forms.

There's some general trouble about the indentation of text.  For instance,
it seems that "The identifier structure is as follows:"
should be 4 spaces to the left, "Non alphanumeric ("special") characters
and spaces are not valid within an Ad-ID." should have a blank like above
it and be moved 3 spaces to the left, and "A Canonical Full Ad-ID ..."
should be moved 1 space to the left.

The production

is incorrect on two counts:  As written, the first character can be zero
(which ix %x30).  The strings generated are 5 characters.  What you want
is

The instances of ALPHA and DIGIT might be intended to be "alpha" and
"digit".  Or do you mean to reference the productions ALPHA and DIGIT in
RFC 5234?  If so, you should eliminate the productions for "alpha"
and "digit" in the draft.

The BNF does not show how the "urn:adid:cuid" URNs are generated.  As the
BNF now stands, those examples are invalid.

It would be helpful here to provide a pointer to the documentation for the
resolvers.

Ditto.

Dale

---

From: Jarrett Wold <[email-masked]>
Date: Wed, 23 Mar 2016 11:25:27 -0400

Hello Dale -
I tried to submit as this as an ID, however, the site is saying the ID
Tool won't be available until 4/3.

I made a lot of changes to the document based on the feedback. I removed
the references to the GUID (probably not needed) and hopefully clarified
more within the doc and references.  Thank you again for your feedback.

Please see the attached draft for review.  Hopefully, this draft is a lot
cleaner.

Jarrett Wold | Ad-ID LLC

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]]
Sent: Monday, March 14, 2016 10:44 PM
To: Jarrett Wold <[email-masked]>
Cc: [email-masked]
Subject: Comments on draft-adid-urn-00

             ABCD0001000

         urn:adid:ABCD0001000
         urn:adid:ABCD0001000H

         urn:adid:cuid:36faeaba

         urn:adid:ABCD0001000
         urn:adid:ABCD0001000H

The production

Ditto.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 30 Mar 2016 14:21:47 -0400

Sorry for the delay getting back to you.

> Tool won't be available until 4/3.

Yeah, no I-Ds can be submitted in the last two weeks before an IETF
meeting.  That way, two weeks before the meeting, you can determine what
you need to read before the meeting.  Submissions resume on the Sunday
at the beginning of the meeting.

Dale

---

From: Jarrett Wold <[email-masked]>
Date: Wed, 30 Mar 2016 15:12:25 -0400

No Worries.  Did you have any other comments regarding document?
Jarrett

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]]
Sent: Wednesday, March 30, 2016 2:22 PM
To: Jarrett Wold <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on draft-adid-urn-00

Yeah, no I-Ds can be submitted in the last two weeks before an IETF
meeting.  That way, two weeks before the meeting, you can determine what
you need to read before the meeting.  Submissions resume on the Sunday at
the beginning of the meeting.

Dale