Re: Domain check in draft-obispo-epp-idn-00.txt
Michael Young <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
Interesting thoughts - I'm really a big fan of avoiding multiple extensions that effectively do the same thing. I think we could benefit by having some more structure around how ICANN works/depends with IETF efforts. Right now it seems pretty reactive to industry needs versus maybe trying to anticipate needs. Michael Young M:647-289-1220 On 2012-01-05, at 1:49 AM, Patrik Fältström <[email protected]> wrote: > On 5 jan 2012, at 04:44, MICHAEL YOUNG wrote: > >> Sorry do you mean if you were designing this from scratch this is what you >> would do? Or do you mean this is how you read one of the existing >> proposals (and by that I mean any of the ones mentioned so far)? > > If we designed epp from the beginning: > > - We would not have the ability for registries to invent their own extensions without IETF review (i.e. like other protocols) > > - We would have optimized a few of the commands (specifically create) so that it is closer to the business models > > Example of the 2nd are all the registries that require delegation at time of registration (something that should be forbidden, but now some registries are like that), that required creation of contact objects and host objects before the domain object is created and glued together. If at that point in time the create fails, the creation of the other objects would have automatically been undone. Maybe as a transaction, I do not know. We should have thought about it harder. > > Patrik > >> Michael >> >> >> >> >> On 12-01-04 10:34 PM, "Andrew Sullivan" <[email protected]> wrote: >> >>> On Wed, Jan 04, 2012 at 07:15:49PM -0500, Michael Young wrote: >>> >>>> the use cases. Somewhere in all that I noted you were ok with the >>>> check ext being optional :-) >>> >>> Actually, you misread, then. I think servers (implementing this >>> extension) MUST support the extension to check. Clients MAY send it >>> or not (which means that implementation is for practical purposes >>> optional for them. >>> >>> Best, >>> >>> Andrew >>> _______________________________________________ >>> provreg mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/provreg >> >> >> _______________________________________________ >> provreg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/provreg >> > _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg