scheme | class of that identified | Notes, supported protocol | Authority/disambiguation |
---|---|---|---|
http | document | Get and put. Can take #fragid | DNS |
service | End point, send or send/receive - does not take #fragid | ||
ftp | file | get and put
(Incomplete architecturally: file format is guesswork) |
DNS |
mailto: | email address ("mailbox") | End point, send. (Also occurs in many other methods in eg IMAP) | DNS |
uuid: | anything | unique, not reused | MAC address (IEEE etc) |
mid: | email message | @@ Can use for anything?
@@ Identify body document separately? |
DNS |
cid: | attachment | @@ anything? @@ body? see mid: | DNS |
md5: | file of octets | No protocol. Directly verifyable. | None |
tel: | telephone number for speech | Human conversation | ITU E164 and national regulators |
fax: | telephone number for fax | End point, send to only. | ITU E164 etc |
urn: | anything. | Various, subscheme-dependent. No general protocol support. | IANA, then subscheme-dependent |
The table demonstrates the diversity of properties of URI schemes, indicating both that the URI system itself was deigned to be very general and allow the craetion of new schemes, but also that a wide range of schemes do exist and should be used rather than re-invented.
@@ represent TAG-relvant questions.