Subject: [Uri-review] registration request for "call:" URI prefix

From: Daniel Pocock <[email-masked]>
Date: Wed, 07 May 2014 09:10:12 +0200

*   URI scheme name
*      call - The call: URI scheme can be used to refer to radio callsigns.  "call:" does not imply an action, it is used as a noun in this context.

*   Status
*      Provisional

*   URI scheme syntax
*      The parameter is a callsign, e.g. for amateur radio call signs:
      call:vk3tqr
      call:M0GLR

*   URI scheme semantics
*      As per the ITU recommendations[1]
      
*   Encoding considerations
*      Only ASCII alphanumeric symbols are permitted.  Case insensitive.
      
*   Applications/protocols that use this URI scheme name
*      Morse code
      
*   Interoperability considerations
*      TBD
      
*   Security considerations
*      None.
      
*   Contact
*      Daniel Pocock, [email-masked]
      
*   Author/Change controller
*      Daniel Pocock, [email-masked]
      
*   References
      *1. http://life.itu.int/radioclub/rr/res-13.pdf*
*

---

From: [email-masked] (Henry S. Thompson)
Date: Wed, 07 May 2014 09:02:10 +0100

This is awfully brief.  It would help evaluate your proposal if you
could explain why you are doing this?  What purpose is served by
having a scheme?

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Daniel Pocock <[email-masked]>
Date: Wed, 07 May 2014 10:07:23 +0200

> could explain why you are doing this?  What purpose is served by

The URI could be used in several ways

It is similar to the tel: URI which describes a phone number but not how
to reach it.

In theory, the call: URI could be allowed in the request line of a SIP
message - that is already permitted for the tel: URI

It could also be embedded in web pages - we could then have a browser
plugin that announces the call in morse code or using the phonetic
alphabet, or it could simply allow the user to click and add the
callsign to their address book.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 May 2014 12:34:46 +0200

> *       call - The call: URI scheme can be used to refer to radio callsigns.  "call:" does not imply an action, it is used as a noun in this context.

Can you make the scheme name more specific? "callsign", for instance?

> *       The parameter is a callsign, e.g. for amateur radio call signs:

What characters are allowed? Is any escaping needed?

> *    Applications/protocols that use this URI scheme name

How does "morse code" use this?

> *       Daniel Pocock,[email-masked]
>
> *       Daniel Pocock,[email-masked]
>
> *    References
>        *1.http://life.itu.int/radioclub/rr/res-13.pdf*

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 May 2014 12:35:53 +0200

> message - that is already permitted for the tel: URI

Is this more than a theoretical use case?

> callsign to their address book.

It seems to me that a media type would be more appropriate for this use 
case.

Best regards, Julian

---

From: Daniel Pocock <[email-masked]>
Date: Wed, 07 May 2014 12:50:57 +0200

On 07/05/14 12:34, Julian Reschke wrote:
>> *       call - The call: URI scheme can be used to refer to radio
>> callsigns.  "call:" does not imply an action, it is used as a noun in
>> this context.
>

callsign: would also be valid, it is just more verbose.

> What characters are allowed? Is any escaping needed?

As mentioned under encoding (below), only ASCII alphanumeric [a-z0-9]
symbols are permitted, it is not case sensitive.  There is no
requirement for escaping.

If it was a URL rather than a URI it could also include information such
as a frequency and transmission mode (e.g. a URL for a repeater might
specify audio, 147.250 MHz, narrow-band FM with +600khz offset)

>From the other email:

SIP doesn't require "sip:" URIs exclusively.  It supports the "tel:" URI
and could also support the "call:" URI
Callsigns can also be used as IRC nicks
AX.25 (not an IETF standard) uses callsigns as an identifier for
packet-based radio networks
Web browsers (and/or browser plugins) could perform various actions when
they encounter such a URI in a page:
- add it to the address book
- announce the callsign in morse code or using the phonetic alphabet
- start a SIP call
- tune a radio to the frequency last used with the callsign or if it is
a URL then tune to the parameters in the URL

---

From: DataPacRat <[email-masked]>
Date: Wed, 7 May 2014 15:42:57 -0400

> callsign to their address book.

Would it be feasible to set up this proposal to allow for future
expansions, for callsigns other than amateur radio callsigns? Eg, for
the imaginary social networking protocol Foobar, something like
call:Foobar:DataPacRat ; with it merely being the default for amateur
callsigns like call:VA3BOS?

Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

---

From: Daniel Pocock <[email-masked]>
Date: Wed, 07 May 2014 21:50:35 +0200

> callsigns like call:VA3BOS?

DataPacRat, this is interesting feedback but I really feel that this
prefix should be used to indicate that the address (the callsign) is
formatted and globally unique as per the ITU standard for callsigns:

http://www.itu.int/online/mms/glad/cga_callsign.sh?lng=E

Also, while my examples were for amateur radio I never stated that it is
exclusively for amateur callsigns.  It is just as valid for ANY callsign
that is unique within the namespace described by the ITU - including FM
radio and TV.

There is also a "tv:" scheme in RFC 2838 but it isn't really the same
thing and it uses domains rather than callsigns.

http://tools.ietf.org/html/rfc2838

---

From: DataPacRat <[email-masked]>
Date: Wed, 7 May 2014 16:00:37 -0400

> http://tools.ietf.org/html/rfc2838

I think I understand you better now - you're proposing, among other
things, that instead of using tv:wned.org to point to the TV station's
online presence, call:WNED would be used to point to its presence
somewhere on the RF spectrum. Fair enough.

That does, however, bring up the point that a lot of the time,
callsigns aren't linked to particular radio frequencies. Do you want
to leave room, at least for possible future expansion, to expand this
proposal to also indicate one or more frequencies, one or more
modulations, and one or more time indications? Eg, so that VA3BOS
could indicate that at such-and-such a time in the future, they plan
to be available on such-and-such a frequency using such-and-such a
modulation; or to indicate that they were previously active on that
frequency. Leaving room for future expansion would still let the basic
format of call:VA3BOS to be considered on its own merits.

As a further thought, 'call' is used a lot more for non-radio purposes
than for radio callsigns, which could lead to some confusion. Are you
sure that that's the prefix you want to use, instead of, say,
'callsign' or 'radio' or the like?

Thank you for your time,

---

From: Daniel Pocock <[email-masked]>
Date: Wed, 07 May 2014 22:26:24 +0200

> format of call:VA3BOS to be considered on its own merits.

This was discussed in another message on this thread - I've also put
some comments about that on my blog

I believe that encoding things like the frequency makes it more like a
URL than a URI.  The URI identifies the station.  The URL identifies one
of potentially many ways to contact that station.

> 'callsign' or 'radio' or the like?

If I understand correctly, URI scheme prefixes should be nouns.  The
verb to "call" is not relevant then.  That is why the "callto:" prefix
is discouraged and prefixes like "sip:", "tel:" and "xmpp:" are used
instead.

As a noun, the word "call" in this proposal is just an abbreviation of
"callsign" and shouldn't be confused with the verb.  However, "callsign"
would be OK too.

One related topic is aviation.  They use similar prefixes to radio
callsigns.  Therefore, the "radio:" prefix may not be ideal if it is
intended that this scheme can describe aviation callsigns too.

http://en.wikipedia.org/wiki/Call_sign#Aviation

Maybe a parameter could be used to distinguish radio and aviation
callsigns, the default being radio

e.g.

call:m0glr

call:m0glr;type=radio

call:N978CP;type=aviation

---

From: DataPacRat <[email-masked]>
Date: Wed, 7 May 2014 16:46:52 -0400

> of potentially many ways to contact that station.

Alright, then; would it be worthwhile to create an URL in parallel to
this URI, which does, in fact, point to particular frequencies and
broadcast methods? (Or a URI, if that would serve better?)

Eg, "At date-times ABC to DEF, transmitter is located at XYZ,
antenna's primary lobe(s) aimed in direction V&W, broadcasting on
frequency N with power P and modulation QM, callsign VA3BOS, with
comments mentioning the topic of conversation will be 'how to keep
dropbears off your homebuilt transmission tower'.".

> is discouraged and prefixes like "sip:", "tel:" and "xmpp:" are used

At least in my local language usage, 'call' is as much a noun as it is
a verb: "I'm going to call my friend" versus "That call went on for
hours".

> call:N978CP;type=aviation

This seems like a workable start. If we're adding parameters to deal
with potential namespace collisions, then another parameter that seems
potentially worth considering is the country issuing the callsign. And
whether country is included or not, should there be some way other
than revising the whole URI format to register additional callsign
types, or will it be a freeform text field?

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Wed, 7 May 2014 17:57:45 -0400

> call:N978CP;type=aviation

If this URI is to include callsigns outside of amateur radio, then
depending on the issuing authority, callsigns are sometimes withdrawn
and reissued to other parties. Would it be worthwhile to include an
optional date parameter, so that the URI indicates "I mean the version
of this callsign that was active on 2015-06-01, not the one that was
active in the 1980s"?

> Encoding considerations
>       Only ASCII alphanumeric symbols are permitted.  Case insensitive.

When I transmit from home, I'm VA3BOS. If I grab my handheld
transceiver and cross a border, my callsign could be "VA3BOS/M"
('VA3BOS mobile') or "VA3BOS/W2" ('VA3BOS portable W2'). I suggest
that the permitted symbols be extended to include, at least, a slash.

Thank you for your time,

---

From: Daniel Pocock <[email-masked]>
Date: Thu, 08 May 2014 09:04:17 +0200

> dropbears off your homebuilt transmission tower'.".

Adding the date/time may be pushing the limits of what belongs in a URL

An iCalendar object could be used to encapsulate the date/time and the
purpose of the contact

The URI and/or URL could be embedded in the iCalendar object as a
participant or location for the "meeting"

> a verb: "I'm going to call my friend" versus "That call went on for
Agreed - but in that context, call does not refer to something that you
identify uniquely.

> types, or will it be a freeform text field?

I'm not certain that these are actual collisions though, just different
use cases.  Some regions/countries may have allowed overlap so it is
better to be safe though.

tel: URIs have a "phone-context" parameter to indicate global scope (the
default) which means that they represent an E.164 number

The scope can also be made local by specifying a value for the
parameter.  It could result in URIs like this:

         call:3tqr;radio-context=vk               ; for vk3tqr

or another pattern I've seen in emergency scenarios involves using the
last character as the station identifier[1].  E.g. using the WICEN
prefix "vk3wi" and station identifiers alpha, bravo, charlie, ...

          call:H;radio-context=vk3wi              ; for vk3wih   /
phonetic identifier for the station is "hotel" (H)

1. http://www.vic.wicen.org.au/wp-content/uploads/2011/05/VK3KBA_ops_man.pdf

---

From: Eric Burger <[email-masked]>
Date: Thu, 8 May 2014 08:19:43 -0400

I’m still lost. Why are we doing this? What is the use case? Who needs interoperability of international radio call signs in Internet protocols?

On May 8, 2014, at 3:04 AM, Daniel Pocock <[email-masked]> wrote:

> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review

---

From: Daniel Pocock <[email-masked]>
Date: Thu, 08 May 2014 14:38:41 +0200

> I’m still lost. Why are we doing this? What is the use case? Who needs interoperability of international radio call signs in Internet protocols?

Why do we have "tel:" URIs and ENUM (RFC 6116) when the PSTN works
perfectly well without the Internet and the ITU works perfectly well
without the IETF?

Eric, did you see the previous emails giving sample use
cases/applications and can you be more specific if you have concerns
with those examples?

---

From: Graham Klyne <[email-masked]>
Date: Mon, 12 May 2014 12:35:55 +0100

> perfectly well without the Internet and the ITU works perfectly well

One reason was a desire to include telephone number information in a context 
where other kinds of URI might also be used.  IIRC, early uses were with 
Internet Fax and SIP, bridging the worlds of PSTN and Internet.

I've no current opinion if this applies to the current debate, though.  One 
touchstone would be to think about the interpretation of

    <a href="call:...">(stuff)</a>

in a web page.  Does it make any kind of sense?  If not, then what's the point 
of a call: URI scheme?

#g
--

---

From: Daniel Pocock <[email-masked]>
Date: Mon, 12 May 2014 13:45:00 +0200

On 12/05/14 13:35, Graham Klyne wrote:
>>> I’m still lost. Why are we doing this? What is the use case? Who
>>> needs interoperability of international radio call signs in Internet
>>> protocols?
>>
>>
>>
> One reason was a desire to include telephone number information in a
> context where other kinds of URI might also be used.  IIRC, early uses
> were with Internet Fax and SIP, bridging the worlds of PSTN and Internet.
>
> I've no current opinion if this applies to the current debate,
> though.  One touchstone would be to think about the interpretation of
>
> in a web page.  Does it make any kind of sense?  If not, then what's
> the point of a call: URI scheme?

It makes about as much sense as putting any other contact data on a web page

Many people and organizations who have callsigns already include them in
web pages or blogs as text

If they can be clicked, then they can be used for a range of purposes. 
For example, there is a lot of third party software for radio amateurs
and some of those software vendors would probably implement handlers for
the URI click events.

---

From: Graham Klyne <[email-masked]>
Date: Mon, 26 May 2014 21:49:05 +0100

Just for the record, I'm not at all persuaded by this response.

What value comes from this being a URI scheme?  Does it behave in ways that are 
consistent with other URIs?  Is it consistent with Web architectural principles? 
  If there is no defined common way to process the URIs, I see no substantial 
value in having them.

#g
--