I'm making a new issue since I believe this is substantial enough to warrant it. Apologies if a comment on #880 would've been preferred.
#880 brings up an issue with relative DID URLs in regards to verificationMethod id fields and this was clarified by #893. However the same issue applies to service entries and they have seen no such clarification.
However I believe there is also a bigger issue with the wording around DID URLs and relative DID URLs in general going on here. The spec repeatedly directly or indirectly talks about relative DID URL references as if it assumes that they are valid URI values per RFC 3986. However they are not valid URIs as URIs are required to have at least a scheme and a path component, and relative references have neither. RFC 3986 calls these values "relative references" and calls a value that's either a URI or a relative reference a "URI reference". The RFC also names a relative reference that refers to the same document and differs only in fragment and calls it a "same-document reference" which seems the most common relative DID URL reference. As such I believe "relative DID URL reference" or perhaps in some cases specifically "same-document DID URL reference" would be a more appropriate term to use.
The exact naming is maybe slightly pedantic but as #880 demonstrates there are also real disagreements here around where relative references are allowed. The CID spec states that id fields in both verificationMethod and service must be RFC 3986 compliant URLs which, as discussed, a relative reference isn't and are thus disallowed under the current wording of the spec. The DID spec now has wording to relax that for verificationMethod ids but not for service ids which is a confusing state from an implementers side. It also has the side effect of making DID documents in general not valid CID documents even though it seems to be the intention is for all valid DID documents to be valid CID documents. In my opinion both specs need a general read over of paragraphs and tables to make sure everywhere that says "URL" or mentions compliance with RFC 3986 are actually using the right wording such that relative references are allowed in the places where they are intended to be allowed. Adding some more examples that include relative references in the places they're supposed to be allowed would probably be good too.
I'm making a new issue since I believe this is substantial enough to warrant it. Apologies if a comment on #880 would've been preferred.
#880 brings up an issue with relative DID URLs in regards to
verificationMethodidfields and this was clarified by #893. However the same issue applies toserviceentries and they have seen no such clarification.However I believe there is also a bigger issue with the wording around DID URLs and relative DID URLs in general going on here. The spec repeatedly directly or indirectly talks about relative DID URL references as if it assumes that they are valid URI values per RFC 3986. However they are not valid URIs as URIs are required to have at least a scheme and a path component, and relative references have neither. RFC 3986 calls these values "relative references" and calls a value that's either a URI or a relative reference a "URI reference". The RFC also names a relative reference that refers to the same document and differs only in fragment and calls it a "same-document reference" which seems the most common relative DID URL reference. As such I believe "relative DID URL reference" or perhaps in some cases specifically "same-document DID URL reference" would be a more appropriate term to use.
The exact naming is maybe slightly pedantic but as #880 demonstrates there are also real disagreements here around where relative references are allowed. The CID spec states that
idfields in bothverificationMethodandservicemust be RFC 3986 compliant URLs which, as discussed, a relative reference isn't and are thus disallowed under the current wording of the spec. The DID spec now has wording to relax that forverificationMethodids but not forserviceids which is a confusing state from an implementers side. It also has the side effect of making DID documents in general not valid CID documents even though it seems to be the intention is for all valid DID documents to be valid CID documents. In my opinion both specs need a general read over of paragraphs and tables to make sure everywhere that says "URL" or mentions compliance with RFC 3986 are actually using the right wording such that relative references are allowed in the places where they are intended to be allowed. Adding some more examples that include relative references in the places they're supposed to be allowed would probably be good too.