m247/epp-client — pull request #8 by jacegu (2014-09-05 09:38:20+00:00)
Title: Domain info response doesn't properly handle <domain:hostAttr> notation for name server info

The domain info response properly handles name server data that comes in the following shape:

```xml

ns1.example.com
ns1.example.net

```

According the [RFC-5731](http://tools.ietf.org/html/rfc5731#section-1.1) a domain's name servers can be specified in two ways: *"Name servers are specified within a `` element. This element MUST contain one or more `` elements or one or more `` elements."*

When `` is used the name and IP addresses should be specified as follows:

```xml

ns1.example.net
192.0.2.2
1080:0:0:0:8:800:200C:417A

```

But the code expects `` and `` nodes instead resulting in a `NoMethodError`:

```
NoMethodError: undefined method `content' for nil:NilClass
/Users/jacegu/Dev/epp-client/lib/epp-client/domain/info_response.rb:27:in `block (2 levels) in nameservers'
/Users/jacegu/Dev/epp-client/lib/epp-client/domain/info_response.rb:26:in `each'
/Users/jacegu/Dev/epp-client/lib/epp-client/domain/info_response.rb:26:in `map'
/Users/jacegu/Dev/epp-client/lib/epp-client/domain/info_response.rb:26:in `block in nameservers'
/Users/jacegu/Dev/epp-client/lib/epp-client/domain/info_response.rb:25:in `each'
/Users/jacegu/Dev/epp-client/lib/epp-client/domain/info_response.rb:25:in `map'
/Users/jacegu/Dev/epp-client/lib/epp-client/domain/info_response.rb:25:in `nameservers'
/Users/jacegu/Dev/epp-client/test/domain/test_domain_info_response.rb:118:in `block (3 levels) in '
/Users/jacegu/.rvm/gems/ruby-2.0.0-p481/gems/shoulda-context-1.1.5/lib/shoulda/context/context.rb:400:in `call'
/Users/jacegu/.rvm/gems/ruby-2.0.0-p481/gems/shoulda-context-1.1.5/lib/shoulda/context/context.rb:400:in `block in create_test_from_should_hash'
```

This PR fixes the parsing of `` nodes adhering to what's described in the RFC and removing the support for the `` and `` nodes.

I'm assuming that those nodes were supported by mistake and that are not used but I may be wrong (maybe they come from a previous version of the RFC?). If that's the case I'd happily extend this PR to provide support for both of them.