A better alternative would be something like this:
https://…” />
This is labelling semantically and providing an extensible format for later
support of other schemes.
Jay
--
Jay Daley
IETF Executive Director
> On 14 Apr 2025, at 09:56, John R. Levine wrote:
>
> On Sun, 13 Apr 2025, Phill
On Mon, 14 Apr 2025, Jay Daley wrote:
A better alternative would be something like this:
https://…” />
This is labelling semantically and providing an extensible format for later
support of other schemes.
That would work although I would be pretty surprised if there were another
identifier
Hi John -
AFAICT from the ORCID website, one use of ORCIDs is to mask personal
identity information. That suggests some policy is needed.
I think adding the field is fine. And I'm staying out of the
bikeshedding discussions about exactly how that field is formatted.
What I would like in a
Agree to adding ability to add ORCIDs, strongly disagree as to mechanism.
ORCIDs should be a URI scheme.
Just tweak the spec to allow multiple URIs.
On Sat, Apr 12, 2025 at 5:42 PM John R. Levine wrote:
> You may have seen some discussions about ORCIDs on the main IETF list.
> Here's a concret
On Sun, 13 Apr 2025, Phillip Hallam-Baker wrote:
Agree to adding ability to add ORCIDs, strongly disagree as to mechanism.
ORCIDs should be a URI scheme.
Just tweak the spec to allow multiple URIs.
No, the point of an field is that you know it's an ORCID and can
do things with it that are sp
Am 13.04.2025 um 18:12 schrieb Salz, Rich:
Technically speaking, this is a link relation type, as defined in RFC
8288 [1].
…
With the existing RFCXML vocabulary, in the content model (“schema”) for
Sounds good.
Do we also want to add a "title" attribute?
Best regards, Julian
Technically speaking, this is a link relation type, as defined in RFC 8288 [1].
…
With the existing RFCXML vocabulary, in the content model (“schema”) for
___
rfc-interest mailing list -- rfc-interest@rfc-editor.org
To unsubscribe send an email to rfc-in
Technically speaking, this is a link relation type, as defined in RFC 8288 [1].
[1]: https://www.rfc-editor.org/rfc/rfc8288#section-2.1
A registry is at:
https://www.iana.org/assignments/link-relations/
[2]: https://authors.ietf.org/rfcxml-vocabulary#address
[3]: https://authors.ietf.org/rfcxml
Maybe this could be made a bit more generic?
Such as...:
http://orcid.org/-0001-7553-5024";>-0001-7553-5024
...which would make it a "typed" .
Is that really less work? I don’t know, can people add any type attribute
without IETF working on it?
_
