validateContactURN generates URN in dubious namespace

[chaos@bbn.com]

This code:

gpoinfra = gmoc.Contact(
             'gpo-infra@geni.net',
             email = 'gpo-infra@geni.net',
           )
print gpoinfra.id

yields:

urn:publicid:IDN+geni.net+user+gpo-infra

It looks like validateContactURN creates a URN space by disassembling the given e-mail address and treating it as an authority and a user part.

I'm not sure this is right, because it might create dubious authority names. In particular, we definitely don't want GPO's infra address to be in the geni.net authority --- maybe that means we shouldn't be using ​gpo-infra@geni.net for this contact, and should be using something in gpolab.bbn.com instead. If we think this is the right behaviour in every other case, then i guess i can change our e-mail address.

But i thought that all URNs monitoring generated on the fly were going to give in gmoc.geni.net, and that seems more correct to me, i.e. that if we need a URN and don't get one, we should always either:

1. Generate one in gmoc.geni.net, or
2. Throw an error

And if A isn't appropriate for whatever reason, that's a good sign that we should be throwing an error. But if organizations and POPs are going to have URNs in gmoc.geni.net, why not non-SA-provided contacts?

[chaos@bbn.com]

Now the code:

gpoinfra = gmoc.Contact(
             'gpo-infra@geni.net',
             email = 'gpo-infra@geni.net',
             givenName = 'GPO',
             lastName = 'Infrastructure Group',
           )
print gpoinfra.id 

yields:

urn:publicid:IDN+gmoc.geni.net+user+gpo-infra+geni.net

Sarah, is it fine to use a + to replace the @ symbol in the e-mail address, or do we need to do something different?

[sedwards@bbn.com]

Hum....

So we said that user URN would follow the rules here: ​http://groups.geni.net/geni/wiki/GeniApiIdentifiers#Name

But that only gives 8 characters for the user name.

If we want to use the email address (which seems reasonable) then perhaps we don't want to be limited by the length and character restrictions of user URNs.

I propose we fall back to Aaron's proposal of using a new URN type:

• URNs should be of type "contact" or something similar
• the allowed characters should follow the general rules for URN which I believe prohibit + and I think prohibit @ but I'm not sure.

[chaos@bbn.com]

Question: are you proposing:

1. A Contact object may be identified by a URN of type user (when Contacts are instantiated by a slice authority) or by a URN of type contact (for non-SA-related contacts)
2. A Contact object must be identified by a URN of type contact (so SAs need to reformat their users as contacts somehow)

I like A as long as it seems okay to y'all protocol folks. I think B sounds painful.

[sedwards@bbn.com]

I'm fine with using a user URN when available.

But if we need to create a new URN, let's use type contact or similar.

[chaos@bbn.com]

Works for me. Rephrasing the proposal:

• If the code ever validates the type of URN (beyond just "is this a valid URN?"), the validator should accept user or contact type URNs
• The code should only generate contact type URNs, and not user type

[sedwards@bbn.com]

Ok. Right now if I input a string, I get an error. If I put in an email address I still get:

urn="urn:publicid:IDN+gmoc.geni.net+contact+jdoe+example.com"

[sedwards@bbn.com]

If I supply an email address, I now get:

urn="urn:publicid:IDN+gmoc.geni.net+contact+jdoe_example.com"/>

If I supply a urn it uses the urn.

So this looks fixed to me.

Closing.