Re: [regext] Implementations of draft-ietf-regext-epp-rdap-status-mapping-01

Hello Ulrich, On 2016-09-13 09:12, Ulrich Wisser wrote: > Hi everybody! > > To finish the document shepherd writeup I would need to include > references to implementations. > Somebody who already has done this? > Who plans on implementing? TANGO Registry Services will implement this mapping. W

Re: [regext] Query: Remove contact:postalInfo from a contact

ment "city" missing), the server removes that element from the contact * if it is not empty, it completely replaces the respective loc/int data * if the contact has loc/int data which is not present in the element, that data is retained, i.e. *not* removed Best regards, Thomas --

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-01.txt

Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel:+49 231 9703-0 Thomas CorteFax:+49 231 9703-200 Stellvertretender LeiterSIP:tho

Re: [regext] draft-ietf-regext-epp-fees-02 : autoRenewPeriod and delete response

when the deletion fees are merely checked for a specific domain name, i.e. to return the credits that would be granted if the domain was deleted at the time the is received. Best regards, Thomas Corte -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH

[regext] draft-ietf-regext-epp-fees-02.txt: should the command name really be optional in ?

flected in the XSD (the attribute is left optional in the "commandType" complex type declaration). Unless the intention was to offer a "wildcard", enabling a client to check all supported command without listing them, this attribute should probably be marked as required. Bes

[regext] draft-ietf-regext-epp-fees-02.txt: may fees/credits be specified in a ?

ions cannot easily be reused for defining requests and responses. Best regards, Thomas Corte -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9

Re: [regext] draft-ietf-regext-epp-fees-02 : autoRenewPeriod and delete response

Hello James, On 2017-03-20 19:22, Gould, James wrote: > Inclusion of grace period credits is timed based (logic executed at > the time of the delete) and is much more involved than returning the > applicable prices. The extension of the availability check command > in draft-ietf-regext-epp-fees-

[regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Hello, I've noticed two more issues with the latest EPP fee extensions draft, detailed below. Generally, I wonder if this mailing list is the right place to report such issues. Should I rather contact the authors directly, or is there a bug tracker set up for this purpose? Issues: 1) There see

Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Hello Roger, On 23/03/2017 16:31, Roger D Carney wrote: > Good Morning, > > Thanks for the comments Thomas! > > I will look at the consistency of the error codes in sections 3.2 and 5.1.1. > > As far as the text in the "avail" section you mention, I think this was > meant as some combination o

Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

chmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel:+49 231 9703-0 Thomas CorteFax:+49 231 9703-200 Stellvertretender LeiterSIP:thomas.co...@knipp.de

Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Hello Bernhard, On 2017-03-24 16:52, Bernhard Reutner-Fischer wrote: > That's what normative references are for IMHO. You wouldn't want to > update the fee RFC if someone invents a new currency. Agreed, that would be cumbersome. > You might want to throw an error if someone configures the serve

Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Hello, On 2017-03-28 15:09, Gould, James wrote: > I had an action item from the working session yesterday to describe > the proposal for the extension to the check response that matches > Option C discussed at IETF-95. The “more complex option” outlined in > the list message > https://www.ietf.o

Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Hello Alexander, On 29/03/2017 00:37, Alexander Mayrhofer wrote: > i think you have mentioned an important argument *against* your own > proposal. You write "availability of a fee (and the domain in > general)", which means that your proposal tries to mix in two > different semantics into the sa

Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Hello James, On 28/03/2017 20:10, Gould, James wrote: > Jody, > > Yes, the fee information should be returned for a reserved domain if pricing > information does exist. Not sure what this would mean. If a domain is reserved, that usually means that it's not available for registration under

Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Hello James, On 28/03/2017 20:09, Gould, James wrote: > Thomas, > > Putting the avail attribute at the level of fee:cd addresses use cases > where the domain name is invalid, reserved (without pricing), and the > currency is invalid. In these cases, you would not want to return all > the comman

Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Hello Jody, On 29/03/2017 15:23, Jody Kolker wrote: > Hi Thomas, > > With the launch of the new gTLDs, we have numerous examples of domains > that are reserved by the registry, but are available for sale given > some circumstances. For this reason, we would like all reserved > domains to be ass

Re: [regext] draft-ietf-regext-epp-fees

Hello Roger, On 29/03/2017 16:05, Roger D Carney wrote: > A few of the items that we resolved Monday include: > > · Simplifying the request by removing the > from the extension. This is more in line with Option C from last year’s > discussions. It does eliminate some flexibility that v

Re: [regext] draft-ietf-regext-epp-fees

Hello, On 29/03/2017 18:25, Alexander Mayrhofer wrote: > · Agreement on failing a create when the passed in fee is not > equal to or greater than what the server expects. Language will be added. > > Alex> Yes, please. Allowing a transaction through when the “bid” is not > sufficient is p

Re: [regext] draft-ietf-regext-epp-fees

Hello James, On 29/03/2017 19:04, Gould, James wrote: > The availability of the domain name and the availability of the fee > information can be separate. Consider the use case where a client does a > check for an existing domain name (e.g., “existing-domain.example”), > where the availability c

Re: [regext] draft-ietf-regext-epp-fees

Hello, On 2017-03-29 23:48, Alexander Mayrhofer wrote: >> Let me be clear that the fee information for an existing domain >> name is based strictly off the fee tables and not looking at the >> fee and credit information of the existing domain itself. > > Interesting point. Of course, for the sak

Re: [regext] draft-ietf-regext-epp-fees

Hello Jody, On 2017-03-30 14:49, Jody Kolker wrote: >> I hope we can agree that in such a situation, the *only* useful fee >> information (e.g. about the cost for a transfer of an affected >> domain) is the *actual* fee attached to the existing domain object, >> and not the *theoretical* (lower)

Re: [regext] draft-ietf-regext-epp-fees

Hello, On 30/03/2017 19:22, Gould, James wrote: > I wouldn’t recommend leaving it up to registry policy on > this one, since the client would not know what to expect. Agreed, it should be left to server policy/configuration whether or not higher than expected values are accepted. Alexander's po

Re: [regext] Contact Postal Info Elements Proposal

_ | | | knipp |Knipp Medien und Kommunikation GmbH ---Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutsch

Re: [regext] Using RDAP as a Domain Availability Service

Hello, On 03/04/2017 17:20, Hollenbeck, Scott wrote: > “However, EPP wasn't designed for high-volume, lightweight availability > checking.” > > That statement is patently false. It may be that some server implementers > constrain clients, but that’s not a protocol limitation. The whole reason >

Re: [regext] Using RDAP as a Domain Availability Service

Hello Andrew, On 2017-04-03 20:35, Andrew Newton wrote: > There's nothing to do about Whois in this case, but RDAP can handle > this easily (hence the extension). While the extension can be briefly specified, its implementation seems excessively costly to me. To make the availability check work

Re: [regext] Using RDAP as a Domain Availability Service

Hello Andrew, On 04/04/2017 21:31, Andrew Newton wrote: > I think it is also worth noting that not all TLDs are the same, and > many do not suffer from these issues and hence should not be held back > in this regard. While that's true, we should also be aware that e.g. ICANN has been requiring c

Re: [regext] domain restore without pendingRestore state

Hello, On 07/04/2017 13:46, Hollenbeck, Scott wrote: > Michael, any registry that implements the ICANN redemption grace period > process is going to use the two-step procedure associated with that process. > If the ICANN process were different, it would make sense for the RFC to have > been wr

Re: [regext] draft-ietf-regext-epp-fees

Hello Roger, On 2017-03-29 16:05, Roger D Carney wrote: > Good Morning, > > We had a very productive meeting at our IETF-98 Monday session. > ... > > I have started work on v3 (0.17) of the draft with these changes in mind. I'm wondering about the status of this new draft version. Is there an

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Hello Roger, On 25/04/2017 23:40, Roger D Carney wrote: > One topic that was discussed in Chicago (and not resolved) was on the > concept of “premium names” and what is returned from the server if no fee > extension was passed into the . Many thought to be more “backwards > compatible”/”user frie

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Hello Roger, On 2017-04-25 23:40, Roger D Carney wrote: > Good Afternoon, > > Here is the update draft document. This should include all of the agreed > upon changes from the Chicago meeting (biggest change was the > simplification of the call). Thanks for this new version. Here are a couple o

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Hello, On 27/04/2017 21:55, Gould, James wrote: > ... > h. In the example, I don’t believe any elements other than > and would be returned when avail=”0”. I > recommend removing the from the example when avail=”0”. Overall, I'm a bit puzzled regarding the usefulness of the "avail" a

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

e from my e-mail). Best regards, Thomas -- | | | knipp |Knipp Medien und Kommunikation GmbH ---Technologiepark Martin-Schmeißer-Weg 9

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

James, On 28/04/2017 15:27, Gould, James wrote: > Thomas, > > There are three classifications of errors that can occur with the fee > extension to the check command: > > 1. Syntax error – This should result in an error for the entire > check command. > > 2. Object (domain) name er

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

James, On 2017-04-28 22:55, Gould, James wrote: > Thomas, > > I’m sorry, I missed the existence of a reason under the command since I > thought the “avail” attribute and the reason element moved from the > command level to the object level. My main concern with providing a > highly feature rich

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Hello, On 2017-05-02 11:39, Thomas Corte wrote: > so. Overall, there seems to be a Meant to write: Overall, there seems to be a high demand among registrars for conveniently obtain comprehensive information about how exactly a certain domain name may be registered, and the command

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Hello James, On 03/05/2017 22:15, Gould, James wrote: > JG – I don’t see how the fee information is tied to availability. The > only case that has recently come up is returning a non-standard domain as > unavailable when the fee extension is not passed. We’ve debated the > extension of the chec

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-04.txt

d41f837d01b94) > between Thomas Corte and I seemed to indicate that option #2 would meet > the needs; although Thomas could weigh in on whether he agrees. Yes, this was the option we agreed upon. Best regards, Thomas -- __

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-04.txt

Hello, On 05/06/2017 21:04, internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Registration Protocols Extensions of the > IETF. > > Title : Registry Fee Extension for the Exten

Re: [regext] interim meetings proposal

Hello Jody, On 21/06/2017 17:18, Jody Kolker wrote: > Thanks Jim/Antion/Adam, > > I fully support having virtual meetings between full IETF meetings. I think > it would help to move documents along faster. Roger and I were discussing > having a meeting for the fee document on July 11th. Wil

Re: [regext] interim meetings proposal

Hello, On 2017-06-27 10:27, Antoin Verschuren wrote: > And for the WG: > To give the chairs and organizer a sense of participation, since this > will be our first interim meeting, who on this mailinglist is thinking > of joining this session? I'm going to join the session (assuming that I can ge

Re: [regext] I-D Action: draft-ietf-regext-epp-fees-05.txt

se, a server is forced to include an (empty) dummy command element to satisfy the schema. Note that the seemingly obvious change (use an XSD between and ) won't work since there may be situations in which commands are present (all unavailable with reason, such as "wrong period")

Re: [regext] REGEXT Interim Meeting

Hello, On 11/07/2017 20:54, Roger D Carney wrote: > We moved on to discussing any new issues/concerns, three items were raised: > > 1. First of which relates to section 3.8 and specifically what happens > when a client does not provide a phase/subphase. We spent the > majority of the me

Re: [regext] REGEXT Interim Meeting

Alexander, On 12/07/2017 09:26, Alexander Mayrhofer wrote: > Later during the day yesterday, i > came up with a very simple requirement that i think would cover my > concerns regarding mixing in launch phases in the fee document: > > - The Fee Extension MUST provide full functionality w

Re: [regext] REGEXT Interim Meeting

Pat, On 2017-07-12 19:18, Pat Moroney wrote: > We actually request fees for future phases so we can sell > pre-registrations and the like. Removing all references to launch phases > would prevent that ability and make things much more complex and prone > to errors. Good point. On that topic, in

Re: [regext] TLD Phase Discovery

James, On 03/08/2017 18:12, Gould, James wrote: > Roger, > > I believe TLD level EPP policies is relevant, but is best suited for > something outside of the Launch Phase or Registry Fee command-response > extensions. An example policy EPP mapping is the Registry Mapping > (https://www.verisign

Re: [regext] TLD Phase Discovery

James, On 04/08/2017 16:58, Gould, James wrote: > Thomas, > > I believe the domain-level availability based on launch phases is a > corner case that as you point out is currently supported by the > Availability Check Form in draft-ietf-regext-launchphase. Providing > trial-and-error probing is

Re: [regext] TLD Phase Discovery

James, On 07/08/2017 17:18, Gould, James wrote: > Thomas, > > My feedback is provided below with a “JG-“ prefix. > > From a high level, we need other registries and registrars to weigh in on > this topic to answer the following: > ... I can see the reasoning behind this outreach, though p

Re: [regext] TLD Phase Discovery

Hello Jody, On 07/08/2017 18:25, Jody Kolker wrote: > Hi Thomas, > > Are the premium names only available in the General Availability phase or are > they available in Landrush or any other early access phases? One of our TLDs offered premium names during the "claims" phase, which was essential

Re: [regext] TLD Phase Discovery

knipp |Knipp Medien und Kommunikation GmbH ---Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel:+49 231 9703-0

Re: [regext] TLD Phase Discovery

Hello Jody, On 2017-08-07 18:53, Jody Kolker wrote: > When a domain is sold to a customer, a check command is sent first to > determine the availability. That check command can be sent without any phase > attributes. > According to the spec when this is done the phase that is currently activ

Re: [regext] TLD Phase Discovery

Hello Roger, On 2017-08-07 18:50, Roger D Carney wrote: > Good Morning, > > Thomas, I think the Fee draft can handle your use case of using launch > phase for premium names (a premium string is only available in one > phase/subphase combination so if client does not pass phase you should > retur

Re: [regext] TLD Phase Discovery

Hello James, On 2017-08-07 20:55, Gould, James wrote: > Use of the phase and sub-phase as a mechanism for clients to indicate > fee or domain grouping categories was not the intent in > draft-ietf-regext-launchphase. At the IETF-98 REGEXT WG meeting it > was unclear when there would be overlappi

Re: [regext] TLD Phase Discovery

in-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel:+49 231 9703-0 Thomas CorteFax:+49 231 9703-200 Stellvertretender LeiterSIP:thomas.co...@knipp

Re: [regext] TLD Phase Discovery

James, On 2017-08-11 19:27, Gould, James wrote: > launch phases are not meant to be a method of grouping domain > names like premium domain names. Says who? As I pointed out in previous e-mails, the launch phase extension spec's wording "Domain names may be made available only in unique la

Re: [regext] Host update and removing V6 glues aka comparison normalized and compressed representation

_ | | | knipp |Knipp Medien und Kommunikation GmbH ---Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

ient systems use a validating parser for registry responses, and it's always a major pain to fix issues when unexpected XML namespaces start showing up. That being said, for some registries (such as Afilias) it seems to be a challenge to even produce schema-compliant server responses whe

Re: [regext] Poll messages with unhandled namespaces (was Re: I-D Action: draft-ietf-regext-change-poll-07.txt)

---Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel:+49 231 9703-0 Thomas CorteFax:+49 231 9703-200 Stellvertret

Re: [regext] [hrpc] Human Rights Review of draft-ietf-regext-verificationcode

Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel: +49 231 9703-0 Thomas CorteFax:+49 231 9703-200 Stellvertretender LeiterSIP:thomas.co...@knipp.de Software-Entwicklung

Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel:+49 231 9703-0 Thomas CorteFax:+49 231 9703-200 Stellvertretender LeiterSIP

Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

tion GmbH ---Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel:+49 231 9703-0 Thomas CorteFax:+49 231

Re: [regext] draft-ietf-regext-epp-fees: add feature to inquire balance and credit limit?

Hello, On 15/05/2019 19:52, Gould, James wrote: > Thomas, > > I view the balance and credit limit information as separate from the > fee information supported by draft-ietf-regext-epp-fees. The balance > and credit limit information can optionally be returned by > draft-ietf-regext-epp-fees, bu

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

-Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel:+49 231 9703-0 Thomas CorteFax:+49 231 9703-200 Stell

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel:+49 231 9703-0 Thomas CorteFax:+49 231 9703-200 Stellvertretender LeiterSIP:thomas.

Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-01.txt

required. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703

Re: [regext] [EPP] Several commands under the same

Hello, On 10/20/22 12:06, Stephane Bortzmeyer wrote: We got a message from a registrar saying that having several commands under an element is legal: ... ... and that "it works with all the other registries". XML schema is difficult to read but RFC 573

Re: [regext] [EPP] Several commands under the same

S® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: thomas.co...@k

Re: [regext] New Version Notification for draft-regext-brown-epp-related-objects-00.txt

objects, querying of such data does become necessary here and there, but there are usually strong restrictions involved (due to GDPR etc.), which again favors an individual inquiry. I'd assume that most registrars would take the same position, but I'm curious to hear other opinions. Bes

[regext] Re: Does section 3.7 of RFC 8748 forbid standard fees for non-standard (aka premium) domains?

tandard (9 USD). Registrars can still use the different "standard" boolean attributes in the response elements to determine the individual "premium situation" for each command. It doesn't seem right to return a different for the same domain depending on the

[regext] Re: ccTLDs using EPP

de awakening. So "using EPP" here really means something like "XML-based provisioning protocol, roughly resembling EPP". Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark

[regext] Re: ccTLDs using EPP

Hello Tobias, On 22.08.24 08:37, Tobias Sattler wrote: I investigated which ccTLD might run EPP a while ago based on publicly available information. I don’t know if those ccTLDs are following this list, and I cannot guarantee its 100% correctness, but maybe it helps you. https://docs.googl

Re: [regext] Unhandled namespaces IETF 102 flashback

Hello Martin, On 10/17/18 17:50, Martin Casanova wrote: > I would like to comment 4 statements(analogous) that were made in this > session: Overall, I agree that all four statements are problematic at best (details inline below). > 1. To make sure the server remains RFC compliant when sending p

[regext] draft-ietf-regext-epp-fees: add feature to inquire balance and credit limit?

lag to the command fee extension, which could trigger the inclusion of the balance/limit in the fee response extension? Best regards, Thomas Corte -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone:

Re: [regext] EPP and rate-limiting

ests" (RFC 6585) but I don't find a proper code in EPP. Any idea? We're using 2502 ("Session limit exceeded; server closing connection") in similar cases. And we're closing the connection, of course. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien un

Re: [regext] EPP and rate-limiting

able response code. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-4

[regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: thomas.co...@knipp.de Germany ___

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

e premium domains. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

Hello James, On 6/26/20 16:18, Gould, James wrote: > but to cover the intent of the RFC the safest approach is to return avail="0" > for a premium domain if the fee extension is not passed in the check command. In my example, the fee extension was passed, but only asking for the *renew* fee (wh

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

uot; for premium names as long as the check command contains *any* fee extension whatsoever. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark Phone: +49 231 9703-222 Mart

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

-breaking change, no? Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

James, On 7/13/20 21:46, Gould, James wrote: > Thomas, > > Signaling support for fee-1.0 in the login services is not material for this > use case. The key element is whether the create of the premium domain name > will fail if the client does not know the correct fee and the fee extension

Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

Hello James, On 7/14/20 14:01, Gould, James wrote: > Thomas, > > The versions of the fee extension that you reference have similar language > associated with returning avail="0" for premium domains: > > 1. fee-0.23 - > https://tools.ietf.org/html/draft-ietf-regext-epp-fees-08#section-4 > 2. f

Re: [regext] EPP Registry Fee Extension: availability check result depending on fee extension?

gistries into adding support for these ancient versions (e.g. by threatening to otherwise not include their premium domains in their portfolios). Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark

Re: [regext] WG LAST CALL: draft-ietf-regext-rfc7482bis

ot; means that a server can choose to e.h. just deliver the contact when there's a registrar with the same handle, that's an acceptably lenient interpretation. Otherwise, no assumption about the uniqueness of entity handles should be made long after the fact. Best regards, Thomas -- TANG

Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

.biz, or the TLDs run by our own TANGO system) already accept them right now. It would be silly to require them to use an extension to do the same in the future. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark

Re: [regext] Contact Postal Info Elements Proposal

ublication? It's not in RFC 5733, and there's no successor for RFC 5733 either. Currently, the only way to find this online is via this mailing list's archive. I'm asking because, as a registrar, we're still seeing lots of different contact update implementations in t

Re: [regext] 2nd WG LAST CALL: draft-ietf-regext-epp-registry-maintenance

Hello, On 3/29/21 14:49, Antoin Verschuren wrote: > The following working group document is believed to be ready for submission > to the IESG for publication as a standards track document: > > https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/ > > EXTRA ATTENTION: Thi

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

Hello, On 8/2/21 15:50, Gould, James wrote: > 2. EPP Contact Response > (https://datatracker.ietf.org/doc/html/rfc5733#section-3.1.2 > ) - The > element is required, which poses an issue when the > registry supports E

Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

Hello, On 8/2/21 20:08, Gould, James wrote: > Thomas, > > For use case #2 (info response of EAI address with non-EAI supporting > client), your preference is to return a failure.  Is 2308 “data > management policy violation” the best error code in your opinion? While not ideal, it seems to be t

Re: [regext] [Ext] Re: I-D Action: draft-ietf-regext-epp-eai-02.txt

Hello, On 8/10/21 02:34, Gustavo Lozano wrote: > I have a comment regarding the following scenario: > > The EAI supporting server MUST satisfy the following obligations when the > client does not support the EAI extension: > > [...] > > When the email property is optional in the EPP response,

Re: [regext] pass on the lower fee

Hello, On 8/17/21 16:30, Mario Loffredo wrote: > Hi Martin, > > at .it we renew every domain automatically but the fee is always the same. > > However, if I understood well, it seems to me that a possible solution > might be a combination of the extensions defined in the two RFCs. > > After al

Re: [regext] pass on the lower fee

Hello, On 8/18/21 14:57, Gould, James wrote: > Martin, > > If you do return the extension in a poll response it should be included in > the greeting services. My recommendation is to fully implement the registry > fee extension along with this so not to cause client confusion. Agreed, adding

Re: [regext] [check] always prohibited when avail="1" ?

Hello, On 9/29/21 13:01, Stephane Bortzmeyer wrote: > RFC 5731 3.1.1 seems to clearly prevent a to be sent when > avail="1". > > But RFC 9095 6.1.1 has an example with a for avail="1". > > So, is it really forbidden to send a to the client when the > domain is available but you want to send

Re: [regext] EPP Extension Object Search

homas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbHThomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund

Re: [regext] EPP Extension Object Search

, frequent registry migrations etc.), adding yet another one to maintain should better be avoided. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmei

Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04

Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: thomas.co...@knipp.de Germany ___ regext

Re: [regext] Comments to the feedback about epp-over-http

a stateful EPP session is surely not desirable, leaving cookies (or some other way to maintain state over multiple HTTP requests) as the only sensible choice. Best regards, Thomas Corte -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH

Re: [regext] Comments to the feedback about epp-over-http

Hello Mario, On 3/29/22 17:07, Mario Loffredo wrote: That's exactly my main concern about such an idea that was the same supporting last proposal about EPP-over-HTTP submitted to this WG. Making EPP completely stateful appeared,and still apeears, to me inefficient and in contrast with the tr

Re: [regext] Comments to the feedback about epp-over-http

Hello Mario, On 3/31/22 13:52, Mario Loffredo wrote: Hi James, For what I have understood, your implementation is based on the assumption that once the HTTP Connection is established, it is used for the transit of all the HTTP requests of an EPP session, starting from the Login and ending w

Re: [regext] Comments to the feedback about epp-over-http

Hello Mario, On 3/31/22 17:36, Mario Loffredo wrote: Starting an HTTP session when receiving an EPP command other than the Login command is in .it experience (but I can speak on behalf of .pl too) very inefficient because you can't immediately lock the HTTP session to the Registrar. Ok, but

Re: [regext] Comments to the feedback about epp-over-http

Hello Scott, On 3/31/22 19:58, Hollenbeck, Scott wrote: [SAH] Client certificates ARE required for TCP transport with TLS. See here: https://datatracker.ietf.org/doc/html/rfc5734#section-9 They're not specifically a requirement for EPP, but they are for that particular transport protocol (wh

  1   2   >