Re: ENUM domain names in Poland

["James Seng" <]

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