H.323 URL Specification (second try)

[Callaghan, Robert]

Paul,

I think that we are in agreement (who would believe this).

I will drop the requirement for case insensitive for the user part.  I would
rather have UTF-8.  The DNS part still must be ASCII and case insensitive.

I hope that Orit, and others, are also in agreement.

Bob

------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756              Fax: +1.561.923.1403
Email:      Robert.Callaghan at ICN.Siemens.com
------------------------------------------------------------------

-----Original Message-----
From: Paul E. Jones [mailto:paulej at packetizer.com]
Sent: Wednesday, September 06, 2000 10:41 PM
To: Callaghan, Robert; Orit Levin
Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail)
Subject: Re: Re: H.323 URL Specification (second try)

Bob,

To prevent the HTML mail headaches, I will comment by item number.

0) Yes, I believe that DNS may be used to locate the "host" and an LRQ then
sent to port "port" of "host".  "host" will resolve the address and return
an LCF.  The user is not necessarily registered with the GK.  Actually, the
LRQ might even be forwarded (available in v4) and the GK to which the user
is actually registered may reply.  Now, that does not mean that the endpoint
has to perform the DNS query and resolve the address-- it may pass it to the
GK for resolution.  The Gatekeeper might also pass it to a border element
for resolution, since Annex G can send templates around with domain names in
them indicating the domains it can resolve.  So, I think there are two
possible resolution mechanisms available to a Gatekeeper.  I believe what I
meant to say I was going to remove is the statement in parentheses about the
LRQ message being used.  Essentially, we're left with just saying that the
default protocol is "ras", which means that a GK should resolve the address.
However, mentioned separately.. somewhere.. that I think it might be
reasonable to specify the resolution "mode" rather than the protocol:
"direct" (i.e., one sends a setup to the address) or "indirect" (i.e., RAS
must be used by the endpoint and the GK may use RAS or Annex G, a database,
a carrier pigeon, etc.)

1) I did not make my point very clear at all-- I apologize.  What I was
trying to say is that users enter aliases, not IP addresses.  Today, most
H.323 users enter telephone numbers or some type of alias and not the IP
address of the called endpoint.  I unsuccessfully tried to draw a parallel
between alias vs IP and user vs host.  In my opinion, the most common forms
of the URL will be either "h323:user at host" or "h323:user".  The former will
be the most popular, by far.  The latter will be more widely used inside
corporate networks.  We see this today with popular e-mail programs, etc.
Some companies are so large that multiple domains are necessary, so it
doesn't work well.  However, most companies keep all e-mail address for the
company under one domain.  So, "h323:user" would be very likely in many
corporate environments.  I prefer to allow these two syntaxes as I believe
they are most common. I do not want "h323:paulej@"-- that I just don't like.

Paul
----- Original Message -----

From: Callaghan, Robert <mailto:Robert.Callaghan at icn.siemens.com>
To: 'Paul E. <mailto:paulej at packetizer.com>  Jones' ; Orit
<mailto:orit at radvision.com>  Levin
Cc: Mailing list for parties associated with
<mailto:ITU-SG16 at mailbag.cps.intel.com>  ITU-T Study Group 16 (E-mail)
Sent: Tuesday, September 05, 2000 10:54 AM
Subject: RE: Re: H.323 URL Specification (second try)

Paul,

See below.

Bob

------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756            Fax: +1.561.923.1403
Email:    Robert.Callaghan at ICN.Siemens.com
<mailto:Robert.Callaghan at ICN.Siemens.com>
------------------------------------------------------------------

(0) The use of url means the "address resolution" is done (by the local GK)
using the DNS, not RAS! This is why the "user only" url of H.323, is really
an exceptional case. It is a question, if we want to keep it within the url.
It lets the local (source) GK know, that the "address resolution" procedure
should performed by other, then DNS, means. The "protocol" means: the
signaling H.323 protocol to contact the (next hop towards the) destination,
after the IP address had been resolved.

(0)   I will remove the reference to RAS and expect to see an explicit
description of the procedure in Annex O.  What I would expect is that the
hostport part will resolve to a GK to which LRQ messages are directed.

 [RWC] Now I am confused.  I thought that DNS was used to locate the
resolution server.  Then LRQ(RAS) was used to communicate with that server
to resolve the address of the user.  The server doing the address resolution
may not be involved in the final connections.


(1) I disagree that it is the exception.  I would contend that calling a
specific machine would be the exception.  Sure, one can call and endpoint
directly, but that's not typical.  It is in testing and development
environments, but in production environments, users enter telephone numbers.
Also, I can imagine intranets where the h323 URL might be used.  At work, I
might post a page with "h323:paulej", but I would never post
"h323:@cisco.com".  However, the latter is allowed, of course.  What I do
not want is "h323:paulej@" on a web page.  That's ugly, in my opinion.  I
realize that the SIP folks chose that, but it seems illogical to me.

[RWC] I do not see any relationship between an URL and a telephone number.
If a user enters a telephone number the connection should be established
using either the dialedDigits alias or the partyNumber alias not the URL-id
alias.  For me, the URL user should be a name type structure like in email
users.  This allows for a number as a name but not as a telephone number.  I
do not accept the SIP and ENUM concept where telephone numbers are funny
names with a default domain for DNS.  In fact, I think that this will not
work due to difficulties with administration ownership of telephone numbers.

[RWC]  I do agree that user only will be an exception because it forces the
use of a default domain for DNS.  It is not likely that there will be
universal default domain.

(2) If I provided "h323:@192.168.1.1;proto=q931", a device should assume
that it can reach it on the default 1720 port or the default Annex E port
(as described in Annex E).  If, however, I use a different port like
"h323:@192.168.1.1:2500;proto=q931", I would say that Annex E is out of the
picture.  That is another reason why I believe the first step to resolution
should be through a Gatekeeper.  The gatekeeper can not only resolve the
address, but also indicate any non-standard ports, including both the TCP
and Annex E transport information.

[RWC] In this case the endpoint that wished to use Annex E must support the
requirement of Annex E that requires the ability to fall back to TCP.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000907/9699c930/attachment-0001.htm>