Re: Standard Extensions

On 23/08/12 17:39, Gould, James wrote:

> 1. Account finance (balance, credit limit, available credit, low credit
> thresholds) information.  Our custom Low Balance Mapping for poll
> messaging of low balance conditions and the Balance Mapping for on-demand
> balance commands. 
> 2. General Key / Value Pair attribute extension which is defined by our
> custom Client Object Attribute Extension.

These would indeed be useful. I think the big reasons they're not used
by other registries are branding (which is silly, but people are still
motivated by these things) and awareness.

> 3. A registry routing extension for servers that support more than one
> TLD.  Our custom NameStore Extension handles this.

I'd prefer to see this moved down to the transport myself. It's good
to be able to share the same physical connection between logical EPP
servers, but embedding that information in the EPP stanza itself is
problematic due to the unfortunate way it interacts with the handshake
and the initially confusing way it interacts with non-domain object
types.

Having routing information like this in EPP stanzas gets very messy on
the client side of things whereas it can be done cleanly in the
transport. That would require an alternative to RFC 5734 though. Done
properly, such an alternative transport could cover the issues the guys
at SIDN were trying to fix with their 'RESTful EPP' proposal by carrying
authorisation information too.

This is essentially what we do internally at Blacknight with our
connection mux daemon. It keeps things very, very clean, and it's only
very marginally more difficult to implement than RFC 5734.

> 4. Additional domain attributes needed to support transfers.  Our custom
> Whois Info Extension supports returning the domain's registrar name, the
> registrar whois server, and the registrar URL to support transfers without
> the need to hit whois for the information.

For thin registries, we end up hitting WHOIS anyway as we have an
in-house 'Universal WHOIS' server which does this all automatically,
along with intelligently caching responses and, soon where possible,
transforming them to a single format.

It's only really useful for thin registries, and it's highly unlikely
the number of thin registries is going to increase.

> 5. Add poll messaging for the expiry of restore commands due to not
> receiving the restore report command in RFC 3915.  Our custom RGP Poll
> Mapping addresses this.

I've always wondered how common it was for the report to be submitted a
long time after the restore request was submitted. We do it pretty much
immediately. It's a pity that RFC 3915 never included <exDate> fields
for when the restore was due to lapse.

> 6. Registry mapping that support returning the list of supported TLD's of
> the server along with features and policy information for the TLD's.  Past
> postings on the list recommended to do this out-of-band, but I still
> believe that this information can and should be provided in-band.

I originally proposed that and suggested it be done in-band originally,
so I'm behind that.

> 7. Support for .NAME objects elsewhere.  Specifically if there is interest
> in support for Defensive Registration or NameWatch objects in other
> registries.

NASK (the .pl registry) have some interesting stuff around this, IIRC.
I'm not sure if there's currently anybody there active on this list, but
it's worth taking a look at.

K.

-- 
Keith Gaughan, Senior Developer
PGP/GPG key ID: 3E896381
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg