<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

RE: ENUM domain names in Poland

  • To: "Conroy, Lawrence (SMTP)" < >
    "James Seng" < >
  • From: "Stastny Richard" < >
  • Date: Wed, 14 Apr 2004 13:24:34 +0200

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 Fltstrm" 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> > >>>> > >>> > >> > >> > >

<<< Chronological >>> Author    Subject <<< Threads >>>