Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(55) |
Nov
(24) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(6) |
Feb
(2) |
Mar
(43) |
Apr
(25) |
May
(12) |
Jun
|
Jul
(9) |
Aug
(32) |
Sep
(6) |
Oct
(5) |
Nov
(3) |
Dec
(4) |
| 2003 |
Jan
(4) |
Feb
|
Mar
(21) |
Apr
(16) |
May
(3) |
Jun
(17) |
Jul
(15) |
Aug
|
Sep
(3) |
Oct
(4) |
Nov
(14) |
Dec
(5) |
| 2004 |
Jan
(7) |
Feb
|
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(26) |
Nov
(4) |
Dec
(14) |
| 2005 |
Jan
(1) |
Feb
|
Mar
(10) |
Apr
(4) |
May
(3) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(10) |
Nov
(7) |
Dec
|
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
(6) |
May
(4) |
Jun
|
Jul
(7) |
Aug
(8) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(8) |
| 2007 |
Jan
(1) |
Feb
(10) |
Mar
(5) |
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
|
| 2008 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
(2) |
May
|
Jun
|
Jul
(4) |
Aug
(6) |
Sep
(11) |
Oct
(11) |
Nov
(22) |
Dec
(39) |
| 2009 |
Jan
(40) |
Feb
(19) |
Mar
(27) |
Apr
(39) |
May
(128) |
Jun
(112) |
Jul
(80) |
Aug
(28) |
Sep
(15) |
Oct
(41) |
Nov
(8) |
Dec
(11) |
| 2010 |
Jan
(9) |
Feb
(6) |
Mar
(46) |
Apr
(57) |
May
(62) |
Jun
(57) |
Jul
(43) |
Aug
(43) |
Sep
(20) |
Oct
(3) |
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(2) |
2
|
|
3
|
4
|
5
(1) |
6
(1) |
7
|
8
(2) |
9
|
|
10
|
11
|
12
|
13
|
14
(3) |
15
(6) |
16
|
|
17
|
18
(5) |
19
(2) |
20
|
21
(3) |
22
|
23
|
|
24
|
25
|
26
(1) |
27
|
28
|
29
|
30
|
|
31
|
|
|
|
|
|
|
|
From: Daniel Manley <daniel@ma...> - 2004-10-26 01:50:59
|
Hi all, does anyone know of an open source generic web client based on EPP -- ie. something to manipulate EPP domain name registry objects and hopefully at least a little bit user-friendly. perhaps something in perl, php or java? Dan |
|
From: Rick Wesson <wessorh@ar...> - 2004-10-21 18:49:24
|
the dash (-) is not allowed in a java package name. epp-ps would be an inappropiate name for that reason. -rick On Thu, 21 Oct 2004, janusz wrote: > Asbjorn, > I assume that you are proposing using "epp-ps" for "proposed standard > and "epp" for "STANDARD". > > If this is the case then I don't see this naming proposal much different > than Rick Wesson's proposal. > > All the issues that were raised so far are valid. > > Regards, > > Janusz Sienkiewicz > > > Asbjorn S Mikkelsen wrote: > > >Hi, > > > >what about calling it "epp-ps" or something similar to show that it is > >"proposed standard"? > > > >Asbjorn > > > > > >On Mon, 2004-10-18 at 17:17, janusz wrote: > > > > > >>Michael Schout wrote: > >> > >> > >> > >>>The 0.9.0 release has the all of exising package names (epp02, epp0402, > >>>epp0503 etc). But the epp0705 package is really EPP 1.0, not EPP 07/05. > >>>This makes it impossible to run the 0.9.0 release with a EPP 1.0 > >>>registry and with .org (07/05) in the same JVM. We are not proposing > >>>removing any of the packages. I was proposing to revert the epp0705 > >>>package to EPP 07/05, and add a NEW package for EPP 1.0. All of the > >>>existing packages would remain (for now at least). > >>> > >>> > >>> > >>> > >>> > >>Existing state of 0.9.0 requires correction. I don't think there is any > >>need for discussion on that. > >> > >>epp0705 should work with EPP 7/5. > >>There should be a new package to run EPP 1.0. > >> > >>The discussion is about what naming convention should be aplied to EPP > >>1.0 package now and in the future when EPP moves from "proposed > >>standard" to "STANDARD". > >> > >>Regards, > >> > >>Janusz > >> > >> > >>------------------------------------------------------- > >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > >>Use IT products in your business? Tell us what you think of them. Give us > >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > >>http://productguide.itmanagersjournal.com/guidepromo.tmpl > >>_______________________________________________ > >>Epp-rtk-devel mailing list > >>Epp-rtk-devel@... > >>https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > >> > >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Epp-rtk-devel mailing list > Epp-rtk-devel@... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > |
|
From: janusz <janusz@ca...> - 2004-10-21 17:48:33
|
Asbjorn, I assume that you are proposing using "epp-ps" for "proposed standard and "epp" for "STANDARD". If this is the case then I don't see this naming proposal much different than Rick Wesson's proposal. All the issues that were raised so far are valid. Regards, Janusz Sienkiewicz Asbjorn S Mikkelsen wrote: >Hi, > >what about calling it "epp-ps" or something similar to show that it is >"proposed standard"? > >Asbjorn > > >On Mon, 2004-10-18 at 17:17, janusz wrote: > > >>Michael Schout wrote: >> >> >> >>>The 0.9.0 release has the all of exising package names (epp02, epp0402, >>>epp0503 etc). But the epp0705 package is really EPP 1.0, not EPP 07/05. >>>This makes it impossible to run the 0.9.0 release with a EPP 1.0 >>>registry and with .org (07/05) in the same JVM. We are not proposing >>>removing any of the packages. I was proposing to revert the epp0705 >>>package to EPP 07/05, and add a NEW package for EPP 1.0. All of the >>>existing packages would remain (for now at least). >>> >>> >>> >>> >>> >>Existing state of 0.9.0 requires correction. I don't think there is any >>need for discussion on that. >> >>epp0705 should work with EPP 7/5. >>There should be a new package to run EPP 1.0. >> >>The discussion is about what naming convention should be aplied to EPP >>1.0 package now and in the future when EPP moves from "proposed >>standard" to "STANDARD". >> >>Regards, >> >>Janusz >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >>Use IT products in your business? Tell us what you think of them. Give us >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >>http://productguide.itmanagersjournal.com/guidepromo.tmpl >>_______________________________________________ >>Epp-rtk-devel mailing list >>Epp-rtk-devel@... >>https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel >> >> |
|
From: Asbjorn S Mikkelsen <asteira@gn...> - 2004-10-21 13:11:57
|
Hi, what about calling it "epp-ps" or something similar to show that it is "proposed standard"? Asbjorn On Mon, 2004-10-18 at 17:17, janusz wrote: > Michael Schout wrote: > > >The 0.9.0 release has the all of exising package names (epp02, epp0402, > >epp0503 etc). But the epp0705 package is really EPP 1.0, not EPP 07/05. > >This makes it impossible to run the 0.9.0 release with a EPP 1.0 > >registry and with .org (07/05) in the same JVM. We are not proposing > >removing any of the packages. I was proposing to revert the epp0705 > >package to EPP 07/05, and add a NEW package for EPP 1.0. All of the > >existing packages would remain (for now at least). > > > > > > > > Existing state of 0.9.0 requires correction. I don't think there is any > need for discussion on that. > > epp0705 should work with EPP 7/5. > There should be a new package to run EPP 1.0. > > The discussion is about what naming convention should be aplied to EPP > 1.0 package now and in the future when EPP moves from "proposed > standard" to "STANDARD". > > Regards, > > Janusz > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Epp-rtk-devel mailing list > Epp-rtk-devel@... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel -- Asbjorn Steira <asteira@...> Development Manager The Global Name Registry, Limited _____________________________________________________ Information contained herein is Global Name Registry Proprietary Information and/or Registry Sensitive Information and is made available to you because of your interest in or affiliation with our company. This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties. Should you have received this email and are not an intended recipient, please delete this email in its entirety. Global Name Registry is registered with the Office of the UK Information Commissioner. |
|
From: janusz <janusz@ca...> - 2004-10-19 13:57:40
|
As far as I know there are no plans to run by .org parallel environments. At some point .org system will be upgraded from EPP 7/5 to EPP 1.0 and only EPP 1.0 version will be available. Regards, Janusz Sienkiewicz Erik Lupander wrote: > Hi again, > > yes, it was a rather large misunderstanding on my part. My belif was > that all the existing 0705, 0503, 0402 a.s.o. packages would be > removed from the RTK and replaced by a single "epp" package. Of course > a new package for Epp 1.0 won't muck up my code. I might add I was a > bit confused when downloading 0.9.0 and "Epp 1.0" was in the 0705 > packages. > > Anyone knows whether .org have plans running parallell EPP environments? > > Thanks! > > --------------------------------------- > Mvh / Regards > > Erik Lupander > Software Development > Domaininfo AB > +46 31 720 20 62 > > > Michael Schout wrote: > >> On Mon, 18 Oct 2004, Erik Lupander wrote: >> >> >> >>> Hi everyone, >>> >>> while being a new subscriber to this list, I work with EPP-RTK -> >>> business system integration on a regular basis. From my point of view, >>> the proposed "epp" package would mess up parts of my software since I >>> utilize the "all-in-one" EPP-RTK as a mean of working with "all" EPP >>> registries from a common JVM. (epp02 for .info, epp0503 for .name >>> a.s.o.) >>> >> >> >> I think you are misunderstanding the issue (or I am misunderstanding >> you) :). >> >> The 0.9.0 release has the all of exising package names (epp02, epp0402, >> epp0503 etc). But the epp0705 package is really EPP 1.0, not EPP 07/05. >> This makes it impossible to run the 0.9.0 release with a EPP 1.0 >> registry and with .org (07/05) in the same JVM. We are not proposing >> removing any of the packages. I was proposing to revert the epp0705 >> package to EPP 07/05, and add a NEW package for EPP 1.0. All of the >> existing packages would remain (for now at least). >> >> I dont see how this would muck up client code at all. When a registry >> migrates, you simply have to change to the "epp" package name in your >> client code and update any API changes. >> >> Regards, >> Michael Schout >> GKG.NET, Inc. >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >> Use IT products in your business? Tell us what you think of them. >> Give us >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >> out more >> http://productguide.itmanagersjournal.com/guidepromo.tmpl >> _______________________________________________ >> Epp-rtk-devel mailing list >> Epp-rtk-devel@... >> https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel >> >> > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Epp-rtk-devel mailing list > Epp-rtk-devel@... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel |
|
From: Erik Lupander <erik.lupander@po...> - 2004-10-19 07:36:31
|
Hi again, yes, it was a rather large misunderstanding on my part. My belif was that all the existing 0705, 0503, 0402 a.s.o. packages would be removed from the RTK and replaced by a single "epp" package. Of course a new package for Epp 1.0 won't muck up my code. I might add I was a bit confused when downloading 0.9.0 and "Epp 1.0" was in the 0705 packages. Anyone knows whether .org have plans running parallell EPP environments? Thanks! --------------------------------------- Mvh / Regards Erik Lupander Software Development Domaininfo AB +46 31 720 20 62 Michael Schout wrote: >On Mon, 18 Oct 2004, Erik Lupander wrote: > > > >>Hi everyone, >> >>while being a new subscriber to this list, I work with EPP-RTK -> >>business system integration on a regular basis. From my point of view, >>the proposed "epp" package would mess up parts of my software since I >>utilize the "all-in-one" EPP-RTK as a mean of working with "all" EPP >>registries from a common JVM. (epp02 for .info, epp0503 for .name a.s.o.) >> >> > >I think you are misunderstanding the issue (or I am misunderstanding >you) :). > >The 0.9.0 release has the all of exising package names (epp02, epp0402, >epp0503 etc). But the epp0705 package is really EPP 1.0, not EPP 07/05. >This makes it impossible to run the 0.9.0 release with a EPP 1.0 >registry and with .org (07/05) in the same JVM. We are not proposing >removing any of the packages. I was proposing to revert the epp0705 >package to EPP 07/05, and add a NEW package for EPP 1.0. All of the >existing packages would remain (for now at least). > >I dont see how this would muck up client code at all. When a registry >migrates, you simply have to change to the "epp" package name in your >client code and update any API changes. > >Regards, >Michael Schout >GKG.NET, Inc. > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >Epp-rtk-devel mailing list >Epp-rtk-devel@... >https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > |
|
From: Michael Schout <mschout@gk...> - 2004-10-18 16:17:48
|
On Mon, 18 Oct 2004, janusz wrote: > The discussion is about what naming convention should be aplied to EPP > 1.0 package now and in the future when EPP moves from "proposed > standard" to "STANDARD". Ok. We are on the same page then :). Regards, Michael Schout GKG.NET, Inc. |
|
From: janusz <janusz@ca...> - 2004-10-18 16:13:55
|
Michael Schout wrote: >The 0.9.0 release has the all of exising package names (epp02, epp0402, >epp0503 etc). But the epp0705 package is really EPP 1.0, not EPP 07/05. >This makes it impossible to run the 0.9.0 release with a EPP 1.0 >registry and with .org (07/05) in the same JVM. We are not proposing >removing any of the packages. I was proposing to revert the epp0705 >package to EPP 07/05, and add a NEW package for EPP 1.0. All of the >existing packages would remain (for now at least). > > > Existing state of 0.9.0 requires correction. I don't think there is any need for discussion on that. epp0705 should work with EPP 7/5. There should be a new package to run EPP 1.0. The discussion is about what naming convention should be aplied to EPP 1.0 package now and in the future when EPP moves from "proposed standard" to "STANDARD". Regards, Janusz |
|
From: Michael Schout <mschout@gk...> - 2004-10-18 15:12:14
|
On Mon, 18 Oct 2004, Erik Lupander wrote: > Hi everyone, > > while being a new subscriber to this list, I work with EPP-RTK -> > business system integration on a regular basis. From my point of view, > the proposed "epp" package would mess up parts of my software since I > utilize the "all-in-one" EPP-RTK as a mean of working with "all" EPP > registries from a common JVM. (epp02 for .info, epp0503 for .name a.s.o.) I think you are misunderstanding the issue (or I am misunderstanding you) :). The 0.9.0 release has the all of exising package names (epp02, epp0402, epp0503 etc). But the epp0705 package is really EPP 1.0, not EPP 07/05. This makes it impossible to run the 0.9.0 release with a EPP 1.0 registry and with .org (07/05) in the same JVM. We are not proposing removing any of the packages. I was proposing to revert the epp0705 package to EPP 07/05, and add a NEW package for EPP 1.0. All of the existing packages would remain (for now at least). I dont see how this would muck up client code at all. When a registry migrates, you simply have to change to the "epp" package name in your client code and update any API changes. Regards, Michael Schout GKG.NET, Inc. |
|
From: Erik Lupander <erik.lupander@po...> - 2004-10-18 14:35:22
|
Hi everyone, while being a new subscriber to this list, I work with EPP-RTK -> business system integration on a regular basis. From my point of view, the proposed "epp" package would mess up parts of my software since I utilize the "all-in-one" EPP-RTK as a mean of working with "all" EPP registries from a common JVM. (epp02 for .info, epp0503 for .name a.s.o.) Sure - if all registries migrate to a Epp 1.0 compatible environment and a common RTK will work seamlessy across registries that is preferable, but as things stand today I would really prefer retaining the current package structure. However - building a personalized RTK combining new and old code/packages isn't much of a hassle so going "epp" is no showstopper by any means. Mvh / Regards Erik Lupander Software Development Domaininfo AB +46 31 720 20 62 |
|
From: janusz <janusz@ca...> - 2004-10-18 14:20:06
|
Rick, Rick Wesson wrote: >could you clarify why we should not expect any changes from "Proposed >Standard" to "STANDARD." As this is the thesis for all your other >arguments please explain in detail how your crystal ball foresees this >future > > There are 2 types of reasons why I am convinced that the likelihood of significant changes between "proposed standard" and "STANDARD" is low. 1. Procedural - the ietf process itself. At this stage it is not that easy to introduce changes to RFC documents as it was when the provreg working group was active. 2. Political. There is several server implementations already implemented that are compliant with "proposed standard". Any changes will try to maintain backward compatibility with "proposed standard" otherwise there will risk of push back from some stakeholders who invested efforts into server implementation. I have no crystal ball. I have no way to deliver a mathematical proof that there will be no changes. If you read my original response again you will see that my reasoning was not solely based on the fact that there will be no changes. >FWIW, the package name will bare little on the developers of epp software >or the market for such packages. > > Now I would ask you whether you have a crystal ball that allows you to see all epp client implementations to make such claim. Quite often clients send us pieces of their code to assist them with resolving some issues. From what I have seen so far I would prefer to make a conservative assumptions. The impact can be bigger that we think. What if a client code uses package name as a part of object creation? Something like this: ObjectType o = <package name>.ObjectType; It is perfectly legitimate coding convention. Do you think that the package name will bare little on the developers in such situations? >BTW, has anyone looked at XMLBeans it kinda obsoletes the RTK... >see: http://xmlbeans.apache.org/ > > >-rick > > > Regards, Janusz |
|
From: Rick Wesson <wessorh@ar...> - 2004-10-15 21:56:30
|
janusz, On Fri, 15 Oct 2004, janusz wrote: > Rick, > > "provreg" IETF working group is already closed. We should not expect > major changes between EPP "proposed standard" and "STANDARD". At this > stage migration from "proposed standard" to "STANDARD" should be > considered as a formal step. could you clarify why we should not expect any changes from "Proposed Standard" to "STANDARD." As this is the thesis for all your other arguments please explain in detail how your crystal ball foresees this future FWIW, the package name will bare little on the developers of epp software or the market for such packages. BTW, has anyone looked at XMLBeans it kinda obsoletes the RTK... see: http://xmlbeans.apache.org/ -rick |
|
From: janusz <janusz@ca...> - 2004-10-15 21:30:41
|
Rick,
"provreg" IETF working group is already closed. We should not expect
major changes between EPP "proposed standard" and "STANDARD". At this
stage migration from "proposed standard" to "STANDARD" should be
considered as a formal step.
Several registries have already launched or are planning to launch
server versions that are compliant with proposed EPP standard. It
makes sense to choose naming convention for the package that will allow
registrars migration to EPP "STANDARD" as smooth as possible.
If we opt "epp2004" as the name for the package and there no significant
differences between "proposed standard" and "STANDARD" registrars and
RTK team may suffer the following negative implications:
1. Many registrars will stay with "epp2004" package as long as
possible. Why should they switch to "epp" if the code is the same?
2. Quite likely RTK team will have to maintain 2 very similiar code
versions for extended period of time.
3. Registrars who want to switch to "STANDARD" RTK will have to modify
their client code (adjusting classpath from "epp2004" to "epp").
Those negative implications may still occur if there are differences
between "proposed standard" and "STANDARD" versions but they are minor
and backward compatible.
Therefore I recommend using generic "epp" name now and later if there
are not major changes between "proposed standard" and "STANDARD". In
case there are significant differences we could create a new generic
name later that implies standard ("epp-rfc" or "epp10" ...).
The advantage of this approach ("epp") is that a new package name is
created only if it is really needed. With the original proposal
("epp2004") there will be always 2 package versions with different
names. There will be always client code changes related to EPP version
migration. Even if there are no changes between the EPP protocol versions.
Regards,
Janusz Sienkiewicz
Rick Wesson wrote:
>janusz,
>
>I am suggesting the the current RFC compliant package be named epp2004
>because it is RFC compliant for a "Proposed standard" and save the "epp"
>package name for the "STANDARD"
>
>There are many classes of RFC and the class we have now for the EPP
>documents is "proposed standard"
>
>-rick
>
>
>
>On Fri, 15 Oct 2004, janusz wrote:
>
>
>
>>Even though the package could be a mearly a placeholder for the future
>>fully RFC compliant implementation using the same generic name like
>>"epp" is a better choice than using "epp2004" now and "epp" later.
>>
>>Let me explain why I think so.
>>
>>If we use suffix "2004" for version that is not fully RFC compliant but
>>it is compatible with majority of existing EPP server implementation and
>>later on implement outstanding RFC features registrars will have to
>>modify their clients code to use RFC compliant RTK package (they will
>>have to switch their classpath from "epp2004" to "epp"). With the
>>generic naming convention such changes will not be required. Client
>>implementors will be able to just replace jar files and client code will
>>continue working.
>>
>>I think it makes sense to adopt naming convention that minimizes impact
>>on registrars of switching from RFC compatible package to RFC compliant
>>package.
>>
>>Regards,
>>
>>Janusz Sienkiewicz
>>
>>Rick Wesson wrote:
>>
>>
>>
>>>I'd recomend we use .epp2004. as the package name as EPP-1.0 is mearly a
>>>placeholder for the IETF Standard the curremnt RFC are only Proposed
>>>Standard and there is another revision we must due before we could say
>>>"epp is a standard" and thus have an unqualified package name.
>>>
>>>-rick
>>>
>>>
>>>On Thu, 14 Oct 2004, Michael Schout wrote:
>>>
>>>
>>>
>>>
>>>
>>>>On Fri, 1 Oct 2004, Daniel Manley wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>or hide the java class packages representing the older EPP versions
>>>>>releases (perhaps going back to plain old "com.tucows.epp.rtk..." with
>>>>>no version marker?). Finally, I've got a couple of domain names in my
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I definately vote that we switch back to the plain "epp" name packages
>>>>(com.tucows.epp.rtk...). The Afilias 0.9.0 release makes the epp0705
>>>>packages EPP 1.0 compliant. Unfortunately, .org has not switched to EPP
>>>>1.0 at this time in production, so we are stuck with the 0.7.5 release
>>>>to interface with .org. .biz on the other hand already has EPP 1.0
>>>>available. If the package names are changed to plain "epp", then I
>>>>could run epp-rtk 0.7.5 and the RFC compliant release in the same
>>>>virtual machine. This would allow us to migrate to EPP 1.0 for .biz,
>>>>and to continue running EPP 07/05 for .org until .org migrates.
>>>>
>>>>Regards,
>>>>Michael Schout
>>>>GKG.NET, Inc.
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>>>>Use IT products in your business? Tell us what you think of them. Give us
>>>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>>>>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>>_______________________________________________
>>>>Epp-rtk-devel mailing list
>>>>Epp-rtk-devel@...
>>>>https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>>>Use IT products in your business? Tell us what you think of them. Give us
>>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>>>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>>_______________________________________________
>>>Epp-rtk-devel mailing list
>>>Epp-rtk-devel@...
>>>https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel
>>>
>>>
>>>
>>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>>Use IT products in your business? Tell us what you think of them. Give us
>>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>_______________________________________________
>>Epp-rtk-devel mailing list
>>Epp-rtk-devel@...
>>https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel
>>
>>
>>
|
|
From: Rick Wesson <wessorh@ar...> - 2004-10-15 20:41:25
|
janusz, I am suggesting the the current RFC compliant package be named epp2004 because it is RFC compliant for a "Proposed standard" and save the "epp" package name for the "STANDARD" There are many classes of RFC and the class we have now for the EPP documents is "proposed standard" -rick On Fri, 15 Oct 2004, janusz wrote: > Even though the package could be a mearly a placeholder for the future > fully RFC compliant implementation using the same generic name like > "epp" is a better choice than using "epp2004" now and "epp" later. > > Let me explain why I think so. > > If we use suffix "2004" for version that is not fully RFC compliant but > it is compatible with majority of existing EPP server implementation and > later on implement outstanding RFC features registrars will have to > modify their clients code to use RFC compliant RTK package (they will > have to switch their classpath from "epp2004" to "epp"). With the > generic naming convention such changes will not be required. Client > implementors will be able to just replace jar files and client code will > continue working. > > I think it makes sense to adopt naming convention that minimizes impact > on registrars of switching from RFC compatible package to RFC compliant > package. > > Regards, > > Janusz Sienkiewicz > > Rick Wesson wrote: > > >I'd recomend we use .epp2004. as the package name as EPP-1.0 is mearly a > >placeholder for the IETF Standard the curremnt RFC are only Proposed > >Standard and there is another revision we must due before we could say > >"epp is a standard" and thus have an unqualified package name. > > > >-rick > > > > > >On Thu, 14 Oct 2004, Michael Schout wrote: > > > > > > > >>On Fri, 1 Oct 2004, Daniel Manley wrote: > >> > >> > >> > >>>or hide the java class packages representing the older EPP versions > >>>releases (perhaps going back to plain old "com.tucows.epp.rtk..." with > >>>no version marker?). Finally, I've got a couple of domain names in my > >>> > >>> > >>I definately vote that we switch back to the plain "epp" name packages > >>(com.tucows.epp.rtk...). The Afilias 0.9.0 release makes the epp0705 > >>packages EPP 1.0 compliant. Unfortunately, .org has not switched to EPP > >>1.0 at this time in production, so we are stuck with the 0.7.5 release > >>to interface with .org. .biz on the other hand already has EPP 1.0 > >>available. If the package names are changed to plain "epp", then I > >>could run epp-rtk 0.7.5 and the RFC compliant release in the same > >>virtual machine. This would allow us to migrate to EPP 1.0 for .biz, > >>and to continue running EPP 07/05 for .org until .org migrates. > >> > >>Regards, > >>Michael Schout > >>GKG.NET, Inc. > >> > >> > >>------------------------------------------------------- > >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > >>Use IT products in your business? Tell us what you think of them. Give us > >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > >>http://productguide.itmanagersjournal.com/guidepromo.tmpl > >>_______________________________________________ > >>Epp-rtk-devel mailing list > >>Epp-rtk-devel@... > >>https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > >> > >> > >> > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > >Use IT products in your business? Tell us what you think of them. Give us > >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > >http://productguide.itmanagersjournal.com/guidepromo.tmpl > >_______________________________________________ > >Epp-rtk-devel mailing list > >Epp-rtk-devel@... > >https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Epp-rtk-devel mailing list > Epp-rtk-devel@... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > |
|
From: janusz <janusz@ca...> - 2004-10-15 19:26:50
|
Even though the package could be a mearly a placeholder for the future fully RFC compliant implementation using the same generic name like "epp" is a better choice than using "epp2004" now and "epp" later. Let me explain why I think so. If we use suffix "2004" for version that is not fully RFC compliant but it is compatible with majority of existing EPP server implementation and later on implement outstanding RFC features registrars will have to modify their clients code to use RFC compliant RTK package (they will have to switch their classpath from "epp2004" to "epp"). With the generic naming convention such changes will not be required. Client implementors will be able to just replace jar files and client code will continue working. I think it makes sense to adopt naming convention that minimizes impact on registrars of switching from RFC compatible package to RFC compliant package. Regards, Janusz Sienkiewicz Rick Wesson wrote: >I'd recomend we use .epp2004. as the package name as EPP-1.0 is mearly a >placeholder for the IETF Standard the curremnt RFC are only Proposed >Standard and there is another revision we must due before we could say >"epp is a standard" and thus have an unqualified package name. > >-rick > > >On Thu, 14 Oct 2004, Michael Schout wrote: > > > >>On Fri, 1 Oct 2004, Daniel Manley wrote: >> >> >> >>>or hide the java class packages representing the older EPP versions >>>releases (perhaps going back to plain old "com.tucows.epp.rtk..." with >>>no version marker?). Finally, I've got a couple of domain names in my >>> >>> >>I definately vote that we switch back to the plain "epp" name packages >>(com.tucows.epp.rtk...). The Afilias 0.9.0 release makes the epp0705 >>packages EPP 1.0 compliant. Unfortunately, .org has not switched to EPP >>1.0 at this time in production, so we are stuck with the 0.7.5 release >>to interface with .org. .biz on the other hand already has EPP 1.0 >>available. If the package names are changed to plain "epp", then I >>could run epp-rtk 0.7.5 and the RFC compliant release in the same >>virtual machine. This would allow us to migrate to EPP 1.0 for .biz, >>and to continue running EPP 07/05 for .org until .org migrates. >> >>Regards, >>Michael Schout >>GKG.NET, Inc. >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >>Use IT products in your business? Tell us what you think of them. Give us >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >>http://productguide.itmanagersjournal.com/guidepromo.tmpl >>_______________________________________________ >>Epp-rtk-devel mailing list >>Epp-rtk-devel@... >>https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel >> >> >> > > >------------------------------------------------------- >This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >Use IT products in your business? Tell us what you think of them. Give us >Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >http://productguide.itmanagersjournal.com/guidepromo.tmpl >_______________________________________________ >Epp-rtk-devel mailing list >Epp-rtk-devel@... >https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > |
|
From: Daniel Manley <daniel@ma...> - 2004-10-15 13:04:23
|
good point Rick. I think this is better name for the classpath. Dan Rick Wesson wrote: >I'd recomend we use .epp2004. as the package name as EPP-1.0 is mearly a >placeholder for the IETF Standard the curremnt RFC are only Proposed >Standard and there is another revision we must due before we could say >"epp is a standard" and thus have an unqualified package name. > >-rick > > >On Thu, 14 Oct 2004, Michael Schout wrote: > > > >>On Fri, 1 Oct 2004, Daniel Manley wrote: >> >> >> >>>or hide the java class packages representing the older EPP versions >>>releases (perhaps going back to plain old "com.tucows.epp.rtk..." with >>>no version marker?). Finally, I've got a couple of domain names in my >>> >>> >>I definately vote that we switch back to the plain "epp" name packages >>(com.tucows.epp.rtk...). The Afilias 0.9.0 release makes the epp0705 >>packages EPP 1.0 compliant. Unfortunately, .org has not switched to EPP >>1.0 at this time in production, so we are stuck with the 0.7.5 release >>to interface with .org. .biz on the other hand already has EPP 1.0 >>available. If the package names are changed to plain "epp", then I >>could run epp-rtk 0.7.5 and the RFC compliant release in the same >>virtual machine. This would allow us to migrate to EPP 1.0 for .biz, >>and to continue running EPP 07/05 for .org until .org migrates. >> >>Regards, >>Michael Schout >>GKG.NET, Inc. >> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >>Use IT products in your business? Tell us what you think of them. Give us >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more >>http://productguide.itmanagersjournal.com/guidepromo.tmpl >>_______________________________________________ >>Epp-rtk-devel mailing list >>Epp-rtk-devel@... >>https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel >> >> >> |
|
From: Daniel Manley <daniel@ma...> - 2004-10-15 12:47:35
|
With the previous version of EPPXMLBase.java (1.3), given the following XML from an EPP registry: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp xmlns:xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="ur n:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"><response><result code="2004"><msg lang="en">Parameter value range error</msg><extVa lue><value xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"><domain:authInfo/></value><reason>Auth info is either too long or too short</reason></extValue></result><trID><svTRID>dotnu-srv1-1097843973</svTRID></trID></response></epp> The RTK reports this... java.lang.NullPointerException at com.tucows.oxrs.epp0705.rtk.xml.EPPXMLBase.parseGenericResult(EPPXMLBase.java:187) at com.tucows.oxrs.epp0705.rtk.xml.EPPDomainUpdate.fromXML(EPPDomainUpdate.java:292) at com.tucows.oxrs.epp0705.rtk.EPPClient.processAction(EPPClient.java:593) at com.tucows.oxrs.epp0705.rtk.example.DomainExample.main(DomainExample.java:617) Dan janusz wrote: > Dan, > from all the links you attached to your posting I still can not figure > out what problem your code changes are trying to solve. All I have so > far is "... code fix for parsing <value> and <extValue> responses from > the server ...". More precise change description would allow > independent code verification by other project stakeholders. > > Im my posting I do not claim that your change is code refactoring. At > the early stage of investigating the issue I had reasons to believe > that the change was "code refactoring". The belief was caused by lack > or inaccurate information. > > Cheers, > > Janusz > > > Daniel Manley wrote: > >> Hi All, >> >> Please take a moment to look at >> https://sourceforge.net/forum/message.php?msg_id=2795713 and post any >> comments you would like. This is in regards to the RFC effort >> Afilias has put into the RTK. >> >> Here's some background and reference material... >> >> As far as I understand it... Afilias started RFC upgrade work in >> June or July before I made the following commit (no other source >> commits have been made anyone from Afilias or otherwise as recorded >> by the epp-rtk-java-commits mailing list): >> http://sourceforge.net/mailarchive/forum.php?forum_id=7610&max_rows=25&style=flat&viewmonth=200407&viewday=29 >> >> >> This is a code fix for parsing <value> and <extValue> responses from >> the server. I found this because because of some domain name >> registry work I was going this past summer (to counteract the >> statement that I have nothing to do with domain names anymore). The >> nature of the change was not cosmetic -- it was a bug fix. There was >> no refactoring, as claimed by Janusz. I did not optomize code or >> move stuff around or other misc nebulous work. The cvs diff of the >> code can be found here... >> >> http://cvs.sourceforge.net/viewcvs.py/epp-rtk/epp-rtk/java/src/com/tucows/oxrs/epp0705/rtk/xml/EPPXMLBase.java?r1=1.3&r2=1.4&sortby=date >> >> >> The code has been tested by me and now the RTK in 0705 properly >> parses <value> and <extValue> elements in server responses. >> >> What's more, this code should not conflict with any RFC upgrades as >> RFC coding would not be done in the epp0705 java classpath. The >> files we would be touching are not the same. Though there would be a >> port-forward required for this bug fix -- and as the author of this >> code fix, I am volunteering to be responsible to doing this when the >> RFC files are committed to CVS. >> >> Anyone, feel free to chime in with comments, concerns or questions. >> >> Cheers, >> Dan >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal >> Use IT products in your business? Tell us what you think of them. >> Give us >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >> out more >> http://productguide.itmanagersjournal.com/guidepromo.tmpl >> _______________________________________________ >> Epp-rtk-devel mailing list >> Epp-rtk-devel@... >> https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Epp-rtk-devel mailing list > Epp-rtk-devel@... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel |
|
From: Michael Schout <mschout@gk...> - 2004-10-14 20:13:50
|
On Thu, 14 Oct 2004, Rick Wesson wrote: > > I'd recomend we use .epp2004. as the package name as EPP-1.0 is mearly a > placeholder for the IETF Standard the curremnt RFC are only Proposed > Standard and there is another revision we must due before we could say > "epp is a standard" and thus have an unqualified package name. Sounds good to me. I just don't like that in the 0.9.0 release epp0705 isnt really EPP 07/05. Mike |
|
From: Rick Wesson <wessorh@ar...> - 2004-10-14 19:47:16
|
I'd recomend we use .epp2004. as the package name as EPP-1.0 is mearly a placeholder for the IETF Standard the curremnt RFC are only Proposed Standard and there is another revision we must due before we could say "epp is a standard" and thus have an unqualified package name. -rick On Thu, 14 Oct 2004, Michael Schout wrote: > On Fri, 1 Oct 2004, Daniel Manley wrote: > > > or hide the java class packages representing the older EPP versions > > releases (perhaps going back to plain old "com.tucows.epp.rtk..." with > > no version marker?). Finally, I've got a couple of domain names in my > > I definately vote that we switch back to the plain "epp" name packages > (com.tucows.epp.rtk...). The Afilias 0.9.0 release makes the epp0705 > packages EPP 1.0 compliant. Unfortunately, .org has not switched to EPP > 1.0 at this time in production, so we are stuck with the 0.7.5 release > to interface with .org. .biz on the other hand already has EPP 1.0 > available. If the package names are changed to plain "epp", then I > could run epp-rtk 0.7.5 and the RFC compliant release in the same > virtual machine. This would allow us to migrate to EPP 1.0 for .biz, > and to continue running EPP 07/05 for .org until .org migrates. > > Regards, > Michael Schout > GKG.NET, Inc. > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Epp-rtk-devel mailing list > Epp-rtk-devel@... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel > |
|
From: Michael Schout <mschout@gk...> - 2004-10-14 17:20:37
|
On Fri, 1 Oct 2004, Daniel Manley wrote: > or hide the java class packages representing the older EPP versions > releases (perhaps going back to plain old "com.tucows.epp.rtk..." with > no version marker?). Finally, I've got a couple of domain names in my I definately vote that we switch back to the plain "epp" name packages (com.tucows.epp.rtk...). The Afilias 0.9.0 release makes the epp0705 packages EPP 1.0 compliant. Unfortunately, .org has not switched to EPP 1.0 at this time in production, so we are stuck with the 0.7.5 release to interface with .org. .biz on the other hand already has EPP 1.0 available. If the package names are changed to plain "epp", then I could run epp-rtk 0.7.5 and the RFC compliant release in the same virtual machine. This would allow us to migrate to EPP 1.0 for .biz, and to continue running EPP 07/05 for .org until .org migrates. Regards, Michael Schout GKG.NET, Inc. |
|
From: janusz <janusz@ca...> - 2004-10-08 21:41:06
|
Dan, from all the links you attached to your posting I still can not figure out what problem your code changes are trying to solve. All I have so far is "... code fix for parsing <value> and <extValue> responses from the server ...". More precise change description would allow independent code verification by other project stakeholders. Im my posting I do not claim that your change is code refactoring. At the early stage of investigating the issue I had reasons to believe that the change was "code refactoring". The belief was caused by lack or inaccurate information. Cheers, Janusz Daniel Manley wrote: > Hi All, > > Please take a moment to look at > https://sourceforge.net/forum/message.php?msg_id=2795713 and post any > comments you would like. This is in regards to the RFC effort Afilias > has put into the RTK. > > Here's some background and reference material... > > As far as I understand it... Afilias started RFC upgrade work in June > or July before I made the following commit (no other source commits > have been made anyone from Afilias or otherwise as recorded by the > epp-rtk-java-commits mailing list): > http://sourceforge.net/mailarchive/forum.php?forum_id=7610&max_rows=25&style=flat&viewmonth=200407&viewday=29 > > > This is a code fix for parsing <value> and <extValue> responses from > the server. I found this because because of some domain name registry > work I was going this past summer (to counteract the statement that I > have nothing to do with domain names anymore). The nature of the > change was not cosmetic -- it was a bug fix. There was no > refactoring, as claimed by Janusz. I did not optomize code or move > stuff around or other misc nebulous work. The cvs diff of the code > can be found here... > > http://cvs.sourceforge.net/viewcvs.py/epp-rtk/epp-rtk/java/src/com/tucows/oxrs/epp0705/rtk/xml/EPPXMLBase.java?r1=1.3&r2=1.4&sortby=date > > > The code has been tested by me and now the RTK in 0705 properly parses > <value> and <extValue> elements in server responses. > > What's more, this code should not conflict with any RFC upgrades as > RFC coding would not be done in the epp0705 java classpath. The files > we would be touching are not the same. Though there would be a > port-forward required for this bug fix -- and as the author of this > code fix, I am volunteering to be responsible to doing this when the > RFC files are committed to CVS. > > Anyone, feel free to chime in with comments, concerns or questions. > > Cheers, > Dan > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Epp-rtk-devel mailing list > Epp-rtk-devel@... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel |
|
From: Daniel Manley <daniel@ma...> - 2004-10-08 20:10:14
|
Hi All, Please take a moment to look at https://sourceforge.net/forum/message.php?msg_id=2795713 and post any comments you would like. This is in regards to the RFC effort Afilias has put into the RTK. Here's some background and reference material... As far as I understand it... Afilias started RFC upgrade work in June or July before I made the following commit (no other source commits have been made anyone from Afilias or otherwise as recorded by the epp-rtk-java-commits mailing list): http://sourceforge.net/mailarchive/forum.php?forum_id=7610&max_rows=25&style=flat&viewmonth=200407&viewday=29 This is a code fix for parsing <value> and <extValue> responses from the server. I found this because because of some domain name registry work I was going this past summer (to counteract the statement that I have nothing to do with domain names anymore). The nature of the change was not cosmetic -- it was a bug fix. There was no refactoring, as claimed by Janusz. I did not optomize code or move stuff around or other misc nebulous work. The cvs diff of the code can be found here... http://cvs.sourceforge.net/viewcvs.py/epp-rtk/epp-rtk/java/src/com/tucows/oxrs/epp0705/rtk/xml/EPPXMLBase.java?r1=1.3&r2=1.4&sortby=date The code has been tested by me and now the RTK in 0705 properly parses <value> and <extValue> elements in server responses. What's more, this code should not conflict with any RFC upgrades as RFC coding would not be done in the epp0705 java classpath. The files we would be touching are not the same. Though there would be a port-forward required for this bug fix -- and as the author of this code fix, I am volunteering to be responsible to doing this when the RFC files are committed to CVS. Anyone, feel free to chime in with comments, concerns or questions. Cheers, Dan |
|
From: Daniel Manley <daniel@ma...> - 2004-10-06 04:29:41
|
Hi all, I've got some code fixes I've discovered for the 0705 stream for the Java rtk. anybody mind if I commit it in so it can make it into the RFC release? I believe the changes are limites to two areas: 1) small improvement in TCP transport so that server socket closes are better detected and thrown; 2) fixes to the implementation of the <value> and <extValue> parsing in server responses. Dan |
|
From: Asbjorn S Mikkelsen <asteira@gn...> - 2004-10-05 16:33:44
|
Dan, I am very sorry to see you leave the project, and would very much like to thank you for all the great work you have done for epp-rtk - everything from doing the IDLs and the Java code, upgraded the c++ code, in addition to helping us out with the GNR-specific mappings for Java. It would have been almost impossible to get the RTKs released without your involvement. Also, thanks for still being available for the next few months and may you find success in all of your future endeavours. Cheers, Asbjorn On Fri, 2004-10-01 at 14:52, Daniel Manley wrote: > Hi gang, > > I'm writing this letter to say that I'm leaving the epp-rtk project. > For a little while now, I've been out of the domain name business, so > it's become very difficult for me to play a contributing role for this > project. Plus other pass-times and hobbies are taking up a lot of my time. > > So, it's with regret that I must leave. Before I go, I'd like to say a > big thank you to a few people.... Scott Hollenbeck for such a > well-written EPP spec and for being there in times of questions and > concerns from us all. The super nice guys at GNR (aka ".name" -- gotta > love that domain!) -- Asbjorn Steira and Vidar Hokstad (who has since > moved on) -- thanks for the C++ RTK and the domtools, and thanks for > collaborating so closely with the project in the early days -- and > thanks for the friendship too. Thanks to Tucows way back when for > creating the project and supporting me in supporting it (remember the > scary days of the possibility of implementing BEEP??? crazy times those > were). Thanks to Rick Wesson for your knowledge and experience and for > keeping close tabs on all the players in this game and for contributing > to SSL stuff and bug fixes. And thanks to Jens-Uwe Gaspar, Rob Mew, > Anthony Eden, Jae Gangemi, among others for their troubleshooting help > throughout the life of the project. > > Now on to the important matters... someone should probably step up to > coordinate releases, update the little web site, bug tracking stuff, > lists, etc. I can provide the passwords to the lists to the > chosen/elected candidate, as well as some quick write-ups I can make for > build procedures, etc. The folks at Afilias have already made a start > at upgrading to RFC for both Java and C++ -- I'll let them chime in > separately as to their efforts so far. The build system for C++ is a > little complicated, as autoconf and automake can naturally be, so I can > provide some guidance from what I remember of setting it up myself. The > Java RTK needs to have some refactoring done to it eventually to remove > or hide the java class packages representing the older EPP versions > releases (perhaps going back to plain old "com.tucows.epp.rtk..." with > no version marker?). Finally, I've got a couple of domain names in my > name for this project which we've never used (epp-rtk.com, etc...). > Those will likely come up for renewal in 2005 sometime. It would be > nice if some could take those off my hands before then (and hopefully > put them to better use than I have). > > So, to help in a transition, I'll stay on the list for a few months or > so, or until I'm no longer needed. Feel free to email me with questions > or concerns -- I'll do the best I can to answer as soon as I can. > > Viva la epp-rtk! ;) > > Dan > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Epp-rtk-devel mailing list > Epp-rtk-devel@... > https://lists.sourceforge.net/lists/listinfo/epp-rtk-devel -- Asbjorn Steira <asteira@...> Development Manager The Global Name Registry, Limited _____________________________________________________ Information contained herein is Global Name Registry Proprietary Information and/or Registry Sensitive Information and is made available to you because of your interest in or affiliation with our company. This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties. Should you have received this email and are not an intended recipient, please delete this email in its entirety. Global Name Registry is registered with the Office of the UK Information Commissioner. |
|
From: Daniel Manley <daniel@ma...> - 2004-10-01 13:53:14
|
Hi gang, I'm writing this letter to say that I'm leaving the epp-rtk project. For a little while now, I've been out of the domain name business, so it's become very difficult for me to play a contributing role for this project. Plus other pass-times and hobbies are taking up a lot of my time. So, it's with regret that I must leave. Before I go, I'd like to say a big thank you to a few people.... Scott Hollenbeck for such a well-written EPP spec and for being there in times of questions and concerns from us all. The super nice guys at GNR (aka ".name" -- gotta love that domain!) -- Asbjorn Steira and Vidar Hokstad (who has since moved on) -- thanks for the C++ RTK and the domtools, and thanks for collaborating so closely with the project in the early days -- and thanks for the friendship too. Thanks to Tucows way back when for creating the project and supporting me in supporting it (remember the scary days of the possibility of implementing BEEP??? crazy times those were). Thanks to Rick Wesson for your knowledge and experience and for keeping close tabs on all the players in this game and for contributing to SSL stuff and bug fixes. And thanks to Jens-Uwe Gaspar, Rob Mew, Anthony Eden, Jae Gangemi, among others for their troubleshooting help throughout the life of the project. Now on to the important matters... someone should probably step up to coordinate releases, update the little web site, bug tracking stuff, lists, etc. I can provide the passwords to the lists to the chosen/elected candidate, as well as some quick write-ups I can make for build procedures, etc. The folks at Afilias have already made a start at upgrading to RFC for both Java and C++ -- I'll let them chime in separately as to their efforts so far. The build system for C++ is a little complicated, as autoconf and automake can naturally be, so I can provide some guidance from what I remember of setting it up myself. The Java RTK needs to have some refactoring done to it eventually to remove or hide the java class packages representing the older EPP versions releases (perhaps going back to plain old "com.tucows.epp.rtk..." with no version marker?). Finally, I've got a couple of domain names in my name for this project which we've never used (epp-rtk.com, etc...). Those will likely come up for renewal in 2005 sometime. It would be nice if some could take those off my hands before then (and hopefully put them to better use than I have). So, to help in a transition, I'll stay on the list for a few months or so, or until I'm no longer needed. Feel free to email me with questions or concerns -- I'll do the best I can to answer as soon as I can. Viva la epp-rtk! ;) Dan |