Opened 12 years ago
Closed 12 years ago
#60 closed (fixed)
validateContactURN generates URN in dubious namespace
Reported by: | chaos@bbn.com | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | 2012-09-04 client release |
Component: | Clients | Version: | |
Keywords: | v0.6.0 | Cc: | |
Dependencies: |
Description
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:
- Generate one in gmoc.geni.net, or
- 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?
Change History (7)
comment:1 Changed 12 years ago by
Keywords: | v0.5.0 added; v0.4.0 removed |
---|
comment:2 Changed 12 years ago by
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.
comment:3 Changed 12 years ago by
Question: are you proposing:
- A
Contact
object may be identified by a URN of typeuser
(when Contacts are instantiated by a slice authority) or by a URN of typecontact
(for non-SA-related contacts) - A
Contact
object must be identified by a URN of typecontact
(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.
comment:4 Changed 12 years ago by
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.
comment:5 Changed 12 years ago by
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
orcontact
type URNs - The code should only generate
contact
type URNs, and notuser
type
comment:6 Changed 12 years ago by
Keywords: | v0.6.0 added; v0.5.0 removed |
---|
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"
comment:7 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
Now the code:
yields:
Sarah, is it fine to use a
+
to replace the@
symbol in the e-mail address, or do we need to do something different?