Mailing list for URLs for conversational services

[Pete Cordell <[e-mail]>]

This mail is to advertise the existence of a mailing list to
discuss/develop conversational URLs.  Toby Nixon has presented an
excellent introduction to this and so I have forwarded it rather than
re-interpreting it in my own words.

Toby mentions collecting existing draft schemes.  Some that I am aware
of include:

H.32x:	ftp://itu-tsg15!avc:ftp.gctech.co.jp/9709_Sun/apc-1288.doc
SIP:	draft-ietf-mmusic-sip-03.txt
Fax:	draft-ietf-fax-addressing-00.txt
Phone:	draft-antti-telephony-url-01.txt
Callto:	See below

One reason for the wide circulation of this mail is to get across the
board consensus on URLs for conversation.  One particular aspect of this
is URLs for phone numbers which is being looked at in a number of areas.

Looking forward to some productive work,

Pete
=================================
Pete Cordell
BT Labs
E-Mail: [e-mail]
Tel: [phone]
Fax: [phone]
=================================


>----------
>From: 	Toby Nixon[SMTP:[e-mail]]
>Sent: 	07 October 1997 02:24
>To: 	'Lars Aronsson'; Ian King; Anders Klemets (VXtreme); 'Vaha-Sipila
>Antti (NMP)'; 'Pete Cordell'; 'Yoav Medan'; 'Matthew Feldman'; 'Henning
>Schulzrinne (BL)'; '[e-mail]'; 'Pnina Vortman'; 'Callaghan,
>Robert NT BOCA'; 'Jim Toga'; 'Bruce A Thompson'; 'Dave Lindbergh';
>'[e-mail]'; 'Tom Taylor'; 'Terry L Anderson'; 'Hong Linh
>Truong'; 'Ami Amir'; 'David Gurle'; 'Henning Schulzrinne (BL)';
>'[e-mail]'
>Cc: 	'[e-mail]'
>Subject: 	Mailing list for URLs for conversational services
>
>Just wanted to be sure you were aware that Scott Petrack has set up a
>mailing list specifically for the discussion of URLs for real-time
>conversations. The list address is "[e-mail]". You can
>subscribe by sending a message with "subscribe" in the message body to
>"[e-mail]". 
>
>It would be great if this work moved forward quickly and we were able
>to
>have a consensus draft as soon as possible. Should we start by
>collecting requirements? From my perspective, I'd like to see a
>consistent URL format for all sorts of conversational services
>including
>H.323, H.324, H.320, SIP, phone, fax, chat, etc. It should allow for
>both technology- and network-specific URLs (i.e., that identify the
>specific network and/or terminal type of the called endpoint) and URLs
>that point to directories, agents, or other higher-level abstractions
>that allow calling a person (wherever they might be) instead of an
>address. Whatever URL format we agree to should be extendable, allowing
>for inclusion of security keys, product-specific extensions, etc.
>
>I do know that there are some existing proposals on the table, such as
>from Henning, Antti, and Pete. Would those who have specific proposals
>already composed please post pointers to them to the mailing list so
>that everyone can review them? Are there any historical documents we
>should have as references?
>
>For information, I've attached below a summary of the "callto" URL that
>is currently supported by Microsoft Internet Explorer and NetMeeting.
>Are there any other existing URLs for similar services for which you
>could post documentation for reference?
>
>	-- Toby
>___________________________________________________________
>Toby Nixon, Program Manager - NetMeeting
>http://www.microsoft.com/netmeeting
>Microsoft Corporation, Applications and Internet Client Group, Redmond
>WA  USA
>[phone]     Fax: [phone]
>mailto:[e-mail]
>
>
>
>THE "CALLTO" URL
>
>Here's some information on the "callto" URL used by NetMeeting 2.0.
>This
>is documented in Chapter 11 of the NetMeeting Resource Kit, which can
>be
>downloaded from http://www.microsoft.com/netmeeting/reskit.
>
>The callto: protocol handler simplifies the process of placing
>NetMeeting calls directly from a web page.  It is designed to mimic the
>functionality of the mailto: protocol handler that is commonly used to
>send e-mail while browsing the web.
>
>Supported syntax in NetMeeting 2.0:
>
>Format				Example
>
>DNS Name			callto:machine.domain.com
>IP Address			callto:157.55.22.31
>E-mail Address*		callto:[e-mail]
>ULS Name
>callto:uls4.microsoft.com/[e-mail]
>
>* This is implemented by resolving the e-mail address against the ULS
>server that the local user is currently logged into.  We want to
>discourage the use of this syntax because it is unlikely to produce the
>correct result as the number of ULS servers increases and users become
>less likely to be on the same server.
>
>		Example HTML:
>
>		<a
>href="callto:uls4.microsoft.com/[e-mail]">Click Here to Call Me
>Using NetMeeting</a>
>
>How callto: can be used (basically like any other URL):
>
>1)	Insert a "call me" link on a personal web page
>
>2)	Use Start->Run->"callto:[e-mail]" to launch NetMeeting
>and place a call
>
>3)	Other apps can ShellExecute() callto: links to integrate with
>NetMeeting without using any APIs
>
>Issues:
>
>1)	callto: wasn't supported prior to NetMeeting 2.0 Beta 2. Of
>course, we hope everyone is upgrading to the latest version.
>
>2)	callto: doesn't currently work in Netscape Navigator.
>
>3)		callto: doesn't currently work in most apps that parse
>text for URL's, including Exchange, Outlook, Word 97, and Internet Mail
>and News.  Internet Mail and News actually parses the e-mail address
>out
>of the callto: link and turns it into a "mailto:" link. This will get
>better as these apps are revised; we're making sure these teams are all
>aware of the callto URL.
>
>4)		callto: doesn't currently support calls through gateways
>(e.g., specifying the gateway name and a phone number), joining an
>existing conference (e.g., specifying an H.323 MCU and conference ID,
>or
>T.120 MCU and conference name), or calls that would need to be resolved
>through a gatekeeper (since RAS isn't supported in NM 2.0). We're
>addressing these issues in future versions of NetMeeting.
>
>It's fairly straight-forward to discover by examining the registry how
>one would register a different app as the "callto" handler. It's just
>like any other URL or file type.
>
>This is for information and not necessarily a proposal for
>standardization. We just want you all to be aware of what's out there
>today, which could become a basis for further work in order to preserve
>backward compatibility. 
>
>