Subject: [IPTEL] RFC 2806bis: phone-context, and other issues

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sat, 22 Dec 2001 17:01:45 -0500

(I vaguely recall that we agreed in London that discussion should take
place on the iptel list. My apologies if my memory is faulty.)

I'm finally fulfilling my promise to edit RFC 2806bis ('tel' URL). Since
this presumably is to go eventually to Draft, I'd like to know how
widely some of the more esoteric features are implemented. Feedback is
most welcome.

- RFC 2806 allows several 'area-specifier's, as in

  tel:7042;phone-context=+1-212-70;phone-context=+1-212-71

  Is this an "OR" match?

  Do clients *have* to support this?

- RFC 2806 allows several service providers, identified by a domain
name. Since there is no current data base that maps domain name to, say,
1010xxxx prefixes (US example), it is not clear how implementable this
is. It is also not clear what the client should do if it doesn't
recognize any of them. Try anyway, using some other carrier? Not try? Is
a URL the right mechanism for conveying this information?

- RFC 2806 allows private dial-plan identifiers (e.g., X-COMPANY-NET),
with a registration scheme left for future definition. That's a bit too
vague for my taste. I propose ditching this or, say, making it a domain
name.

All of these seem like features that should be added later, as
extensions, once we understand how they can be useful. Unless we have
two interoperable implementations, they'll have to be dropped in any
event. Thus, please let me know if you either have implemented these or
plan to implement these.

Also, this would be a good opportunity to remind me of any other issues
or extensions that should go into the 2806bis draft.

Thanks.

Henning
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Brett Tate" <[email-masked]>
Date: Sat, 22 Dec 2001 20:31:17 -0500

> I'd like to know how widely some of the more 
> esoteric features are implemented. Feedback is
> most welcome.

<snip>
 
> vague for my taste. I propose ditching 
> this or, say, making it a domain name.

We are currently making use of the private 
dial-plan functionality.
 
> or extensions that should go into the 

Section 1.2 rfc2806bis-00 discusses escaping
not unreserved characters.  It would be
helpful to add a sentence clarifying that 
"+", ";", "=", etcetera do not need to 
be escaped if they are explicitly
presented in non-escaped form as part of 
the syntax.  This would explain why "+"
does not require escaping when used within
a global-network-prefix; however it would 
require escaping when present within a 
private-prefix.

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 23 Dec 2001 10:14:13 -0500

Brett Tate wrote:

> require escaping when present within a

Added:

Note that the reserved characters ``+'', ``;'',
``='', and ``?'' {\MUSTNOT} be escaped if shown in the grammar
definitions below as they are delimiters for the tel/fax/modem URI
schemes.  These reserved characters {\MUST} be escaped if they appear in
parameter values.

Let me know if this is not sufficiently clear.