-----Original Message-----
From: James Seng [
]
Sent: Wednesday, April 14, 2004 5:03 PM
To: Stastny Richard; Conroy, Lawrence (SMTP)
Subject: Re: ENUM domain names in Poland
Nope, I dont think we should put both variant in the DNS in the long run.
But it does sound like it is a "good practice" to put it into DNS for now.
We
can also discuss a 'flag day' where we declare 'By 1st Jan 2006, everyone
switch to 2916bis only'.
Lawrence, if you working on the doc, pls circulate :-)
-James Seng
----- Original Message -----
From: "Stastny Richard" <Richard.Stastny@localhost
To: "Conroy, Lawrence (SMTP)" lwc@localhost; "James Seng"
jseng@localhost
Sent: Wednesday, April 14, 2004 7:24 PM
Subject: RE: ENUM domain names in Poland
Lawrence wrote:
Yes - I've already considered adding this as part of the ENUM grand
unified
Implementers Guide/BCP. I guess someone should summarise this thread
on
the
IETF ENUM mailing list - any offers?
Back from vacation:
Interesting that as soon somebody is proposing some real work to
be done the discussion is dying away immediately ;-)
IMHO putting both variants in ENUM is not a good idea.
Upgrading existing ENUM clients to understand both 2916 and
2916bis is also not a good idea, because it is unnecessary
work.
The best solution would be to upgrade all existing 2916 based
ENUMs with a simple scripting run to 2916bis overnight.
Following rationale and way forward:
-2916bis is approved and only stuck in IANA, so it will come
(although nobody seems to know when ;-)
-the argument of some implementers of ENUM that they are
obliged to implement only RFCs I cannot follow really, because
in this case they could not implement ENUM at all, because
not a single "enumservice" is defined in an RFC yet.
- at least for Europe there is existing a BCP already,
defineing very well all what needs to be done to be compatible,
namely ETSI TS 102 172.
- the document should be updated accordingly to the developments
over the last year and parts of it could then easily folded back
to the IETF Grand BCP document proposed in Korea (still waiting on
input from the far east ;-)
- there will be an ETSI TISPAN WG4 meeting in two weeks, where
updates to ETSI TS 102 172 will be discussed.
-I will be happy to receive input for this document and forward
it to ETSI during the next week and also afterwards.
-the results of this updates may be folded back in an ID for San Diego.
-this leaves also time to finalize then both documents until October,
(the second ETSI ENUM Plugtest Workshop)
to use both the ETSI document and the IETF document as basis
for the ETSI Plugtest event in December.
We should not forget that some ENUM implementations will go
commercial mid of this year and more will follow until the
end of the year.
If 2916bis is not an official RFC within mid of the year, the
only feasible way (at least in Europe) will be to use the
ETSI TS anyway.
Another option is to remove the IANA stuff from RFC2916bis in
A similar way it is done with 2806bis by Jonathan (quod licet Jovi,
also licet bovi ;-)
best regards
Richard
-----Original Message-----
From: Conroy, Lawrence (SMTP) [
]
Sent: Wednesday, March 31, 2004 7:12 PM
To: James Seng
Subject: Re: ENUM domain names in Poland
Hi James, folks,
<note>
First point - due to a good example of I.T. departments at their
very
best,
any mail with a dot in the subject is not readable by a certain
would-be reader
of this thread - please could folk remove the dot I inadvertently put
onto the
end of the title before posting. Mea culpa.
</note>
Yes - I've already considered adding this as part of the ENUM grand
unified
Implementers Guide/BCP. I guess someone should summarise this thread
on
the
IETF ENUM mailing list - any offers?
I have to say I still have qualms over this as it doubles the size of
the
replies which IS a problem for existing implementations that
realistically
cannot be changed as they're already on the limit of available size in
the
JVM on some cell phones (before someone jumps in :). Of course, if
everyone
went out and purchased a new smartphone, then this would not be a
problem,
(as they wouldn't be running long enough to get a response back :).
However... it IS a migration strategy, and given the sterling work
IANA
and the RFC Editor have done** to ensure that I retire before we have
a
clear replacement, it may be the least bad solution.
all the best,
Lawrence
** You might think of a Banana Republic, but I couldn't possibly
comment.
On 31 Mar 2004, at 5:16 pm, James Seng wrote:
just a matter of curiousity...how many implementations are still
using
2916
and not 2916bis?
ps: it does make sense to put both 2916 and 2916bis in the record.
perhaps
someone should put together a BCP.
james
----- Original Message -----
From: "Andrzej Bartosiewicz" andrzejb@localhost
To: "Patrik F�ltstr�m" paf@localhost
Cc: "Conroy, Lawrence (SMTP)" lwc@localhost; "Stastny Richard"
<Richard.Stastny@localhost; enum-trials@localhost
Sent: Wednesday, March 31, 2004 6:15 PM
Subject: Re: ENUM domain names in Poland.
I guess they still use RFC 2916 format.
yes, we are still using 2916 format for NAPTR RRs
My *personal* recommendation is to use both 2916 and 2916bis
format
for
a while as software might not be updated yet according to 2916bis.
i think it's good idea to support both 2916/2916bis for a while.
for
example
our "look-up" & "phone book" applications are still based on
rfc2916:
www.dns.pl/cgi-bin/en_enum_lookup.pl
www.dns.pl/ENUM/enumClient.zip
andrzej
paf
On Mar 31, 2004, at 01:29, Conroy, Lawrence (SMTP) wrote:
Hi Andrzej,
looking at the first number (+48225231300) , I note that the ENUM
data
is broken.
The service field is "mailto+E2U" - in RFC2916bis the E2U goes at
the
start of
the field, NOT the end.
Likewise for the second number.
Sigh.
See ETSI's TS 102 172 for the ETSI spec on Interoperability of
European trials.
all the best,
Lawrence
----
On 29 Mar 2004, Andrzej Bartosiewicz wrote:
We are using this domain names for testing in Poland.
Please, do not call me and my friends in the middle of the
night...
;)
Andrzej.
0.0.3.1.3.2.5.2.2.8.4.e164.arpa
0.2.9.7.5.0.0.0.6.8.4.e164.arpa
<snip>