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@ICN.Siemens.com
------------------------------------------------------------------
-----Original
Message-----
From: Paul E. Jones
[mailto:paulej@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@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 -----
To: 'Paul E.
Jones' ; Orit
Levin
Cc: Mailing list for parties associated with
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@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.