Subject: Re: [VCARDDAV] Groups

From: Chris Newman <[email-masked]>
Date: Wed, 12 Mar 2008 10:47:35 -0500

Speaking as a technical contributor,

Please think about not having a "group" kind and instead having a 
"memberof" attribute that lists the groups to which a vCard entry belongs. 
It's not clear to me the architecture benefits from treating a group as an 
explicit object, rather than treating a group as an implicit object that 
results from a search.

If we create what is fundamentally a new type of vCard object it's going to 
require a lot more change to existing vCard software than if we add an 
attribute and a search model to instantiate a group implicitly.

		- Chris

--On February 27, 2008 18:15:19 -0500 Cyrus Daboo <[email-masked]> wrote:

> Hi folks,
> One thing that has been briefly discussed before is the issue of how to
> represent a "group" via a vCard. The idea here is that most address books
> provide some form of "group" support and it would be nice if that could
> be  exchanged via vCards as well as the "individual" contact information.
>
> We do have a new KIND property that can have the value "group", but there
> is no property to list the members of the group. So should we have a
> MEMBER  property? This could appear multiple times and its value would be
> a URI. It  would be handy if the URI could be a urn:uuid where the uuid
> is actually  the UID value of a vCard, but I think in that case the UID
> has to follow  the uuid format requirements. If that is so should we
> insist on UID values  being uuids as per RFC4122. On a CardDAV server the
> URI could be an http  URI to a vCard on the server.

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 12 Mar 2008 11:04:01 -0400

Hi Chris,

--On March 12, 2008 10:47:35 AM -0500 Chris Newman <[email-masked]> 
wrote:

> "memberof" attribute that lists the groups to which a vCard entry
> belongs. It's not clear to me the architecture benefits from treating a
> group as an explicit object, rather than treating a group as an implicit
> object that results from a search.
>
> If we create what is fundamentally a new type of vCard object it's going
> to require a lot more change to existing vCard software than if we add an

That would prevent me from e.g., creating my own group that includes a 
vcard that is shared to me as read-only, since memberof would require a 
change to the shared vcard. This is a vert likely scenario where e.g a 
corporate carddav server exposes a "public" (but read-only) view of the 
corporate directory, and users will want to create their own "ad-hoc" 
groups from those directory-based vcards.

Also, how are groups actually going to be used? I would argue that groups 
are used in an "expansion mode" - i.e. a "return all members of this group" 
type query. Whereas, "memberof" is more geared to a "is X a member of the 
group Y" type query. I think the former is much more important than the 
later.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Wed, 12 Mar 2008 11:29:01 -0400

> groups from those directory-based vcards.

This is easily addressed by also having a MEMBER property. This reminds 
me of UNIX groups: you can specify group members in /etc/group, and you 
can also specify a group of which a user is a member in /etc/passwd. 
Having both directions is feasible.

> group Y" type query. I think the former is much more important than the 

Not really. Look at the following:
(I used GROUP instead of MEMBEROF to address ugliness issues.)

BEGIN:VCARD
FN:My mailing list
KIND:group
UID:mml
END:VCARD
BEGIN:VCARD
FN:Joe Member
GROUP:mml
END:VCARD
...

Isn't this pretty? You can stick this inside a single file even more 
easily than it would be to have hierarchical vCards.

I'm leaning more and more toward never having vCard hierarchies. This 
would also make CardDAV not need modifications for handling them. It 
would also be easier for implementors because they wouldn't be required 
to understand groups to at least have access to the contained members.

The only case of hierarchy we have now is the AGENT property. I suggest 
that this be changed so that it works in a manner similar to the above 
example.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Wed, 12 Mar 2008 09:54:28 -0700 (PDT)

On 2008-03-12/11:04 [-0400], [email-masked] [Cyrus Daboo] wrote:

> > belongs. It's not clear to me the architecture benefits from 
> > treating a group as an explicit object, rather than treating a group 
> > as an implicit object that results from a search.
> >
> > If we create what is fundamentally a new type of vCard object it's 
> > going to require a lot more change to existing vCard software than 
> > if we add an attribute and a search model to instantiate a group 
> > implicitly.
> 
> vcard that is shared to me as read-only, since memberof would require 
> a change to the shared vcard. This is a vert likely scenario where e.g 
> a corporate carddav server exposes a "public" (but read-only) view of 
> the corporate directory, and users will want to create their own 
> "ad-hoc" groups from those directory-based vcards.
> 
> Also, how are groups actually going to be used? I would argue that 
> groups are used in an "expansion mode" - i.e. a "return all members of 
> this group" type query. Whereas, "memberof" is more geared to a "is X 
> a member of the group Y" type query. I think the former is much more 
> important than the later.
>

Why not have a vcard that represents a group and specifies the guid for 
the group.  Then you set that guid in all contact vcards that belong to 
that group.  To expand the members of a group, one has to simply search 
for all vcards where memberOf=<guid>.

If static membership and specially members that reside in external 
contact data sources is desired, then we can have static members defined 
in the groups vcard entry.  I do think including references to remote 
entries will require having to deal with dangling references and so we 
should, in the interest of simplicity, leaving it out for now.

-- 
_______________
Anil SRIVASTAVA  |  [email-masked]  | Sun Microsystems, Inc
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 12 Mar 2008 14:37:13 -0400

Hi Simon,

> Having both directions is feasible.

Only when you have control over both files. If you can't write to 
/etc/passwd, then you can't keep the back links correct and so the utility 
of having those at all is reduced as you can't rely on them.

>> this group"  type query. Whereas, "memberof" is more geared to a "is X a
>> member of the  group Y" type query. I think the former is much more

Again this only works if you have write access to the FN:Joe Member vCard. 
If you do not you cannot create a group including that vcard.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 12 Mar 2008 14:39:31 -0400

Hi Anil,

> should, in the interest of simplicity, leaving it out for now.

I believe that sharing in CardDAV is going to be a primary use case, and 
that will likely mean that vCards people want to have in groups will be 
read-only, so having them refer to the group will not work reliably.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Wed, 12 Mar 2008 15:02:31 -0400

Cyrus Daboo wrote:
> /etc/passwd, then you can't keep the back links correct and so the 
> utility of having those at all is reduced as you can't rely on them.

Well, of course you're always free to make your own copy. And you don't 
even need back links. Just have a group point to someone or vice versa, 
and that's it. You just need to edit one part.

>> BEGIN:VCARD
>> FN:My mailing list
>> KIND:group
>> UID:mml
>> END:VCARD
>> BEGIN:VCARD
>> FN:Joe Member
>> GROUP:mml
>> END:VCARD
>> ...
> 
> Again this only works if you have write access to the FN:Joe Member 
> vCard. If you do not you cannot create a group including that vcard.

Yes you can. Here's the other way around:

BEGIN:VCARD
FN:My mailing list
KIND:group
UID:mml
MEMBERS:joem
END:VCARD
BEGIN:VCARD
FN:Joe Member
UID:joem
END:VCARD

That's the whole point: we can have it both ways. It worked for UNIX 
accounts.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 13 Mar 2008 06:17:33 -0200

Hi Chris,

> Newman wrote,

The KIND attribute was first thought for representing organizations as vCard 
entities (kind="org" vs. kind="individual"). It addresses the situation 
explained in Section 5.1.5 of draft-resnick-vcarddav-vcardrev-01. Then Cyrus 
a suggested a "group" kind, on the same basis (thus groups are no longer 
represented as fake "individual" instances).

He pointed out that  [[

  iCalendar has a CUTYPE parameter for ATTENDEE's defined as:

     cutypeparam        = "CUTYPE" "="
                         ("INDIVIDUAL"          ; An individual
                        / "GROUP"                   ; A group of individuals
                        / "RESOURCE"            ; A physical resource
                        / [...]
]]

Note that KIND alters the traditional (version <= 3) semantic of the vCard 
entity, which now holds only for the "individual" kind.

For instance, one would not expect a N property within an "org" or "group" 
vCard). The "group" is different from "org" because only the latter is 
related to ORG properties on the member-side (thus member's "ORG" might 
identify the organization of which the entity is "member of", up to name 
equivalence). It is not clear to me which other assumtions are made for the 
"group" kind.
(btw, I would like to see it briefly explained somewhere in the spec...)

> to

I'm not sure about this assertion. I think no special handling is REQUIRED 
for the KIND property (though an application MAY benefit from it).

A minimal port from version 3 to version 4 may treat "kind" as a new 
property with no particular meaning, delegating to the user the 
responsability of deciding which semantics applies for that kind,
Besides, the default "individual" kind makes unnecessary to deal with KIND 
at all if all vCards are interpreted from the RFC 2426 (individual-only) 
point of view.

On the other hand an enhanced application might use the kind value for 
displaying the vCards according to their kind and/or disallowing some 
properties which do not make sense for that kind.

Best Regards

Javier

P.S. I hope I had understood your concern in the right direction...

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 13 Mar 2008 10:13:22 -0200

Hi Simon,

Simon Perreault wrote,

> Look at the following:

Currently AGENT value is agent-inline-value / agent-refer-value /
text-value, with agent-refer-value = uri

1.  I have previously suggested that MEMBER (aka. MEMBEROF, aka. GROUP)
mimics the AGENT property (i.e. inline values) because "some device may not
support URI resolution, and they may
prefer to store it as a vCard entity (perhaps with a SOURCE referring to the
original URI)."

A hierarchy with multiple levels is rather complex. If an application can
support it, one could expect it could support UID references too, because
they are simpler. My argument above does not hold if one replace "URI" by
"UID", therefore I see no problem with droping the inline feature in favor
of UID references.

2. By defintion, there is no global *resolution* mechanism for vCard UIDs.
Since agent-refer-value is a URI, it makes possible to refer the agent's
vCard location (on an external system), or an identifier for it that may be
globally resolved.

I advocate for using URIs instead of UIDs for that purpose, because when the
vCard is exported, if only UIDs were used then either all the related
vCards should be exported or the references would be broken.

However, only a subset of URI schemes is applicable, and software can handle 
a smaller subset of URI schemes and URN namespaces. Thus one have to choose 
carefully which scheme will be used, UIDs are good in some contexts, URIs 
are preferable in others..

3. If we define a vcard: URI scheme (as Cyrus suggested) then UID references 
would be URI references, with the additional advantage of having 
"vcard:123456" referring some vcard from contexts other than the vCard 
itself (e.g., a search system, which could also return URIs according to 
other schemes). UIDs and URIs share the same semantics, hence this step 
seems reasonable to me.

The locality issues would be addressed in the same way as for other URI 
schemes that can not be resolved globally. If the intent is to refer a vCard 
that is available within the scope of UID resoultion, then vcard: would be 
used; on the other hand, if the intent is to provide a stable reference 
(e.g., for exchanging vCards among remote systems), then other schemes would 
be available (btw, data: URLs might be used for inline vcards, if an 
implementation deems it necessary after the agent-inline-value is dropped).

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Thu, 13 Mar 2008 09:05:56 -0400

> prefer to store it as a vCard entity (perhaps with a SOURCE referring to 

If it mimics the AGENT property (as it exists now), then you gained 
nothing because it can be a URI.

Storing references inline is very important. You may not have access to 
the remote place. You may not even have access to a URI resolution 
service! So the discussion really is about:

Is it better to store referred vCards as inline values or as separate 
vCards?

i.e. This:

BEGIN:VCARD
AGENT:BEGIN:VCARD\n...\nEND:VCARD
END:VCARD

vs. this:

BEGIN:VCARD
AGENT:blah
END:VCARD
BEGIN:VCARD
UID:blah
END:VCARD

Substitute AGENT for GROUP or MEMBER if you wish.

The latter is much better because:

1. You don't need a recursive parser.
2. It solves the problem of recursive queries in CardDAV by simply 
eliminating them.
3. It's simpler to split into multiple/contactenate from multiple resources.

I would allow the value to be either a UID or a URI because both make 
sense. For example when you concatenate multiple vCards in a single .vcf 
it makes sense to use a UID to make cross-references. In the context of 
a CardDAV server you might want to use either UID or URI. UID would mean 
that the referred contact is in the same collection, while URI could 
refer to a contact in a separate collection.

> A hierarchy with multiple levels is rather complex.

Yes. But having inline vCards doesn't prevent that. Here's an example:

BEGIN:VCARD
AGENT:BEGIN:VCARD\nAGENT:BEGIN:VCARD\\n...\\nEND:VCARD\nEND:VCARD
END:VCARD

Note the recursive parsing needed. This is not good.

> If an application can

Exactly, and that's why we need both UID and URI.

> 3. If we define a vcard: URI scheme (as Cyrus suggested) then UID 
> references would be URI references, with the additional advantage of 
> having "vcard:123456" referring some vcard from contexts other than the 
> vCard itself (e.g., a search system, which could also return URIs 
> according to other schemes). UIDs and URIs share the same semantics, 
> hence this step seems reasonable to me.

This is a clever trick to have UIDs appear as URIs. I would actually 
argue against it because:

1. It's not needed.
2. There's no way to resolve it universally.
3. Clever tricks are evil.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 13 Mar 2008 17:16:15 -0200

Hi Simon,

Simon Perreault wrote:

>> support URI resolution, and they may prefer to store it as a vCard entity (perhaps with a SOURCE referring to  the original URI)."
> 
> service! 

That is why, when URI resolution services may be unavailable, the alternative would be an embedded (either inline or concatenated) vCard *with* a SOURCE property referring to the original URI. If you cannot access the resoultion service, there is no problem because enough information was provided by the inline entity. It does not impedes you from using the URI if the service is accessible. I think it is a nice combination if embedded vCards are to be used.

> So the discussion really is about:
> 

Well... I missed the point in my previous mail. I thought it was about inline versus references. Now it is clear to me.

> 3. It's simpler to split into multiple/contactenate from multiple resources.

I agree. The vCard format is very simple, but for the agent-inline-value.

> 3. Clever tricks are evil.

1. We are using UIDs as if they were URIs. Whether they are raised to true URIs or not, its semantics remains the same: they are expected to be "globally unique and persistent" (as URNs are) and they can be resolved under some constraints. Hence, we have an URI-like identifier, the only difference is that we are not using the "vcard:" prefix. 

2. There are other URI schemes / URN namespaces that cannot be resolved, or resolution is possible within a local scope. Some of these schemes I can remember now are:

tag: (no resolution defined)
urn:uuid (local resolution only but global uniqueness)
urn:publicid (uniqueness is not guaranteed for non-formal public identifier and formal public identifier with unregistered owners. Resolution would be possible up to identifier conflicts)

3. I agree, but I would not call it a "trick" but a "matter-of-fact": as exposed in 1, if we are going to allow ( uri / uid ) as references I don't see why keep an artificial distinction which was introduced 10 years ago... or maybe I'm missing some other property of URIs that UIDs don't share.

Best Regards

Javier

---

From: Chris Newman <[email-masked]>
Date: Thu, 13 Mar 2008 17:52:59 -0500

The other way to deal with read-only cards is to view them as a 
cache/update issue.  If there's a read-only vcard for some user, I want my 
laptop to pull down a copy into my addressbook where I can add my own notes 
about that vcard (and put it in the group I want) and then synchronize that 
to my phone.  I also want to keep a link to the original read-only source 
so the system notices when that changes and updates it.  If the original 
source vanishes, then I still have the card -- no astonishment when it 
suddenly disappears.

To me, this is the key difference between a corporate directory (where the 
server always stores canonical data) and a personal address book (where I 
control all the content).

I would find it incredibly frustrating to have a UI that prevented me from 
editing any field in any entry in my address book.

		- Chris

---

From: Chris Newman <[email-masked]>
Date: Thu, 13 Mar 2008 18:02:34 -0500

--On March 13, 2008 3:17:33 -0200 Javier Godoy <[email-masked]> 
wrote:
> I'm not sure about this assertion. I think no special handling is
> REQUIRED for the KIND property (though an application MAY benefit from
> it).

For individual vs. org, I have no problem with KIND -- many address book 
clients have this distinction and it would be a small change to the 
software to bind the "is a business/organization" UI element to the KIND. 
Even implementations without the concept an org just has a different 
preferred display attribute from an individual -- the same meaning applies 
to all the vCard attributes.

But a group requires a completely different UI model and groups may not be 
conceived as physical objects by all implementations (just as modern 
mailstores may not treat a mailbox as a physical object).  A UI can't 
usefully present a group without a complete group UI model.  I suspect many 
implementations don't store vCards as vCards internally and while they 
might update mappings for vCard 4.0 they won't change internal data 
structures.  For such implementations a group vCard kind becomes a NULL 
vCard entry with no semantically useful attributes.  I just don't see the 
almost non-existent benefit of this change (relative to a memberof 
approach) being worth the interoperability cost.

		- Chris

---

From: Simon Perreault <[email-masked]>
Date: Thu, 13 Mar 2008 18:07:31 -0400

Chris Newman wrote:
> I just don't see the 

Is it just me or do we already have exactly this functionality with the 
CATEGORIES property?
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Peter K. Sheerin" <[email-masked]>
Date: Thu, 13 Mar 2008 15:27:36 -0700

IMHO, UID is the best way to avoid duplication and deletion problems when synchronizing. Without it, what good
hooks are left to do this reliably with?

>> 6) Did we decide on whether UID should be mandatory in a vCard? If so, we
>> need to include that in the vcard definition comment in Section 6.
>
>The status quo from RFC 2426 is that UID isn't mandatory. I would argue 
>against it being made so.

---

From: Anil SRIVASTAVA <[email-masked]>
Date: Thu, 13 Mar 2008 15:27:21 -0700 (PDT)

I think this is a good model.  

Is it upto the address book client to merge the changes between the 
cached copy and the canononical copy stored in the corporate address 
book?  

I should mention this model is also used by Plaxo, with the key 
difference being they setup connections between an entry in users 
personal address book and other registered users.  The system notifies 
the user of any updates to contacts and then a user can accept/reject 
the change.

Anil
 
On 2008-03-13/17:52 [-0500], [email-masked] [Chris Newman] wrote:

> cache/update issue.  If there's a read-only vcard for some user, I 
> want my laptop to pull down a copy into my addressbook where I can add 
> my own notes about that vcard (and put it in the group I want) and 
> then synchronize that to my phone.  I also want to keep a link to the 
> original read-only source so the system notices when that changes and 
> updates it.  If the original source vanishes, then I still have the 
> card -- no astonishment when it suddenly disappears.
> 
> To me, this is the key difference between a corporate directory (where 
> the server always stores canonical data) and a personal address book 
> (where I control all the content).
> 
> I would find it incredibly frustrating to have a UI that prevented me 
> from editing any field in any entry in my address book.
> 
> 		- Chris
> 
> > > Why not have a vcard that represents a group and specifies the 
> > > guid for the group.  Then you set that guid in all contact vcards 
> > > that belong to that group.  To expand the members of a group, one 
> > > has to simply search for all vcards where memberOf=<guid>.
> > > 
> > > contact data sources is desired, then we can have static members 
> > > defined in the groups vcard entry.  I do think including 
> > > references to remote entries will require having to deal with 
> > > dangling references and so we should, in the interest of 
> > > simplicity, leaving it out for now.
> > 
> > I believe that sharing in CardDAV is going to be a primary use case, 
> > and that will likely mean that vCards people want to have in groups 
> > will be read-only, so having them refer to the group will not work 
> > reliably.
> > 
> > --
> > Cyrus Daboo

_______________

---

From: Simon Perreault <[email-masked]>
Date: Thu, 13 Mar 2008 18:37:15 -0400

Peter K. Sheerin wrote:
> IMHO, UID is the best way to avoid duplication and deletion problems 
> when synchronizing. Without it, what good
>> The status quo from RFC 2426 is that UID isn't mandatory. I would 
>> argue against it being made so.

Actually my opinion on this has changed during this week. We've 
discussed this in the context of the live meeting of the vcarddav 
working group in Philadelphia. It will be made mandatory in the next draft.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Chris Newman <[email-masked]>
Date: Thu, 13 Mar 2008 19:18:02 -0500

> Is it just me or do we already have exactly this functionality with the

The "memberof" semantic is somewhat different (albeit similar to) the 
categories property semantic.  The categories is just a list of things for 
which a search can be performed, while "memberof" implies the existence of 
a search group.  I would not object to altering the definition of 
CATEGORIES, but the backwards compatibility impact should be considered 
before deciding to do that.

		- Chris

---

From: "Peter K. Sheerin" <[email-masked]>
Date: Thu, 13 Mar 2008 22:02:22 -0700

Great! The spec should also be more specific about how to create a UID, 
to increase the chances that it will actually be unique. The current RFC 
has vague suggestions, but the example isn't clearly derived from any 
existing unique ID spec, and so far as I can tell, there is no 
iana-token that qualifies as a decent UID. (This issue was raised on 
microformats, I believe.)

What should it be? What about RFC 4122?

---

From: "Javier Godoy" <[email-masked]>
Date: Fri, 14 Mar 2008 06:55:15 -0200

Hi Peter,

Peter K. Sheerin wrote:

> Great! The spec should also be more specific about how to create a UID, to
> increase the chances that it will actually be unique.

I think RFC 2426 prefered to be lax about identifiers, which may have been
appropriate in 1998 but (IMHO) it is a bad idea today since we have a good
theoretical background about globally unique identifiers (namely URI).

When one is comparing several vCards according to their
UIDs (for synchronizing or whatever), one usually assumes that the
identifiers didn't change.Hence UIDs should be persistent too (as required
by vCard 2.1 or dropped later on RFC 2426)

As I understand the UID definition, you MAY use a URI (thus adhering to a
well-know identifier system) or you MAY use an implementation-specific
identifier (a text-value UID), which is "required to be globally unique" and
provide my own uniqueness rationale.

Suposse I'm trying to be "clever", and I say "I will use my own name as
identifier, because I don't know anyone else with my exact name" thus I
choose UID:JavierGodoy... This would have never happened if I had been
REQUIRED to use URI. If I were really sure that my own name is a good
identifier within my system because of my very own reasons (e.g. because I'm
not so clever ;-)... I would have better chosen
"urn:publicid:JavierGodoy", under the uniqueness considerations of
RFC 3151.

The advantage with URI schemes is that each one has a different approach to
uniqueness, persistence and resolution concerns. If you need resolvable
identifiers (globally, or locally) there is a good set of schemes with this
property. If you need a persistent identifier, you might use a URN. If you
think you should not use a URI because your requirements are not satisfied
by any existing scheme, chances are that you are either misunderstanding the
URI properties, or you have discovered a situation where a new scheme should
be defined.

I think we should get rid of free-text UIDs (or justify why they should be
kept). There have been some discussion about a lax "vcard:" URI. Though I'm
not sure if we really need to be lenient about identifiers, I think this
issue is best discussed in the URI domain (as I have explained my point in
previous e-mail I'm not repeating it here).

> The current RFC has vague suggestions, but the example isn't clearly
> derived from any existing unique ID spec, and so far as I can tell, there
> is no iana-token that qualifies as a decent UID. (This issue was raised on

http://www.ietf.org/mail-archive/web/vcarddav/current/msg00094.html
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00109.html

UUID (RFC 4122) is a good choice for locally generated but globally unique
identifiers, the bad news are that UUID resolution is limited to the system
scope.
If global resolution were an issue, I would prefer urn:fdc (RFC 4198) at the
expense of a larger identifier string.

Best Regards

Javier