Should the versioned identifier really be `primary`?

[strogonoff]

https://github.com/ietf-ribose/relaton-data-ids/blob/c718c948c536e833b69279324bd278a2f4916b4b/data/draft-wang-pce-vlan-based-traffic-forwarding-04.yaml#L14-L20

I believe Internet Drafts are primarily cited by unversioned identifiers, so it looks like assigning primary to the versioned identifier is a mistake?

This breaks the automatic association of given Internet Draft versions to be shown together on the same page. The association works by a primary identifier, and now it is different for every draft.

This lack of association is all the more a problem because we have no relations—so the user cannot easily navigate to the latest draft if they ended up on an old draft (and the user may not even know that the draft they’re viewing is not the latest one).

[strogonoff]

Related: https://github.com/ietf-ribose/relaton-data-ids/issues/13

[strogonoff]

Nick supports the idea of switching the primary identifier to the unversioned one.

[strogonoff]

Resolved, as far as I can tell.

[strogonoff]

No, not resolved:

https://github.com/ietf-ribose/relaton-data-ids/blob/5a3e9e30ec278b946d8943ea0300f3a51a38d518/data/draft-ietf-perc-dtls-tunnel-11.yaml#L15-L21

@ronaldtse, I believe the idea is to have unversioned I-D… identifier as primary. Here, the versioned identifier draft-ietf-perc-dtls-tunnel-11 is primary (and I-D with space is missing).

[ronaldtse]

@strogonoff may I be reminded why the unversioned ID is the primary one? Ping @opoudjis too

In any case, this anchor is correct and should not be changed:

 - id: I-D.wang-pce-vlan-based-traffic-forwarding 
   type: IETF 
   scope: anchor 

[opoudjis]

RFC XML v3 captures the versioned ID of Internet drafts in seriesInfo: https://datatracker.ietf.org/doc/html/rfc7991#section-2.47.6

Citations are actually in practice with user-supplied tags:

https://datatracker.ietf.org/doc/html/rfc8000

[[SEC-ADD]()]  Lever, C., "Federated Filesystem Security Addendum", Work
              in Progress, https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-federated-fs-security-addendum-06, October 2016.

So it's not that big a deal, and the ID is retrieved by the URL anyway.

[strogonoff]

@ronaldtse for BibXML, it is a bigger deal:

1) IETF mentioned a few times that they actually tend to use unversioned IDs when citing 2) BibXML service lists standards that share the same primary identifier on the same page. This is important for UX.

Is there a reason we don’t want to do it? If so (why?), we really should add superseding/superseded relations between I-Ds (#6), because with neither primary docid nor relations the user may be browsing outdated I-D version and we can’t hint that a newer one exists.

[strogonoff]

 - id: I-D.wang-pce-vlan-based-traffic-forwarding 
   type: IETF 
   scope: anchor 

No argument about the anchor. However, earlier I believe we used to have I-D wang-pce-vlan-based-traffic-forwarding (without the dot) or draft-wang-pce-vlan-based-traffic-forwarding (without the version) as primary. Once the primary identifier was switched to versioned draft (without my knowledge), UX broke (draft versions are no longer listed on the same page).

It doesn’t mean we need to omit the versioned one, we’d just make it non-primary or even perhaps have two primary docids if that’s OK with Relaton spec.

[ronaldtse]

@ronaldtse for BibXML, it is a bigger deal:

1. IETF mentioned a few times that they actually tend to use unversioned IDs when citing
2. BibXML service lists standards that share the same primary identifier on the same page. This is important for UX.

Agree.

Is there a reason we don’t want to do it? If so (why?),

No, as long as we have both the versioned and the unversioned identifiers present. Both of them are valid identifiers, but I want to be sure that there is a semantic difference.

we really should add superseding/superseded relations between I-Ds (#6), because with neither primary docid nor relations the user may be browsing outdated I-D version and we can’t hint that a newer one exists.

100% agree. Can you propose how we should do this?

Personally, I would argue that the correct way of doing this is to separate the two pieces of information:

1. The versioned I-D is by itself. We mark it as "belonging" to the I-D series (the unversioned version) through a relation.

2. The unversioned I-D exists separately. Within this unversioned I-D, it contains relationships to all its versioned copies (the bibdata in 1).

The BibXML Service offers both as citable information.

[strogonoff]

@ronaldtse

Can you propose how we should do this?

I believe the most practical way to address this right now—unless this would have unintended consequences—is simply:

• Add another docid (or, rather, bring back previously deleted one), which is an unversioned I-D identifier marked as primary.

I would argue that the correct way of doing this is to separate the two pieces of information

While this may be more correct, it is not strictly necessary to address the immediate problem.

BibXML service already can show draft versions on the same page. The only thing BibXML service needs to actually do this is that single draft versions have the same unversioned identifier marked as primary. If all draft versions have the same primary identifier, they will be united in GUI.

The approach you suggest would offer some benefits (separate bibliographic items for quoting unversioned vs. versioned Internet Draft make sense to me), but also require some GUI adjustments to reduce the number of clicks user needs to arrive at the latest version (with my suggestion above it’d happen by default). I think we’re short on time to do this in this iteration…

[ronaldtse]

Add another docid (or, rather, bring back previously deleted one), which is an unversioned I-D identifier marked as primary.

Sounds reasonable.

The approach you suggest would offer some benefits (separate bibliographic items for quoting unversioned vs. versioned Internet Draft make sense to me), but also require some GUI adjustments to reduce the number of clicks user needs to arrive at the latest version (with my suggestion above it’d happen by default). I think we’re short on time to do this in this iteration…

Agree. I do think the information on the GUI can be dynamically fetched if we do this way, but I do not know if xml2rfc is going to support this.

[strogonoff]

I filed a ticket to add a new primary unversioned docid.