9 Bře
2015
9 Bře
'15
18:55
On Mon, 2015-03-09 at 17:03 +0100, Jaromir Talir wrote:
Hi Mark,
what we do on server side is just simply pass incoming XML through XML
Schema validation process. This is practically the same as calling
"xmlling --schema our_epp_schema.xsd epp_message.xml". We do that just
to avoid any incompatibility problems in further processing.
What you see is the output of this call.
So I'm trying to find the binary "xmlling". Lots of "look at
xmllint" -
no xmlling... I run Gentoo. Can you suggest the name that this binary
might be in - eg xml-tools... (or did you mis-spell?)
Also - where can I get the appropriate schema from (or is this a bad
path to follow) ?
I understand that this may cause problem to a general
client. However,
maybe you are aware that FRED has slightly different schema (nssets
instead of hosts) so your client needs to be ready for differences in
any case.
That is a different problem eg COZA uses "host attributes" instead of
"Host objects" - so I expect to have to add some new XML to properly
support FRED.
Do you supply a full schema list? - or rather all the different EPP XML
commands?? (ie examples) .... That would fix my knowledge problem.
Regards,
Jaromir
On Mon, 2015-03-09 at 17:47 +0200, Mark Elkins wrote:
--
Mark James ELKINS - Posix Systems - (South) Africa
mje(a)posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
On Mon, 2015-03-09 at 16:26 +0100, Piotr Przybył
wrote:
On 09/03/15 16:21, Mark Elkins wrote:
Thanks for the quick reply.
That helps - I get a valid reply. However - the samples in the RFC's use
the "abbreviations" - and are they not what one should be following?
This also means you are sending longer messages (unnecessary bytes?).
I do understand the suggestion of using the FRED Client - I was trying
to avoid that if possible... and trying to instead follow what (I
interpret) the RFC's say..
CoCCA was initially barfing on the "Longer form" and I actually trimmed
many of these down to what seemed like a common denominator on all the
other EPP systems I use the same code for. I guess clients can't pass a
switch in the Login to change this behaviour????
_______________________________________________
fred-users mailing list
fred-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users Hi,
I'm successfully connecting to and able to login to FRED (demo) at TZNIC
- using the EPP Library that CentralNIC wrote (all PHP) - with some
modifications.
However - all "commands" after that seem to return the same (similar)
error message.
I've looked and copied examples from RFC5731...
As an example - the Info Command...
C:<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name hosts="all">example.com</domain:name>
C: </domain:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
So I actually send:
<?xml version="1.0" encoding="UTF-8"
standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<info>
<domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
and get back:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="2001"><msg>Command syntax
error</msg><extValue><value><domain:info
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name hosts="all">dnssec.or.tz</domain:name>
</domain:info></value><reason>Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element declaration
available, but demanded by the strict
wildcard.</reason></extValue></result><trID><svTRID>ReqID-0002778177</svTRID></trID></response></epp>
What seems to be common is "Schemas validity error: Element
'{urn:ietf:params:xml:ns:domain-1.0}info': No matching global element
declaration available, but demanded by the strict wildcard." and I have
no idea what that means.
What should I be sending then????
...and from a debugging prospective - getting the reply on more or less
one line is real hard to read for a Human. Yes - a Machine has no
problem. I wish there was a switch for "Human Readable XML" - all
neatly grouped and indented like in the RFC documents.
In case its my login - it looks like this - except with User/Passwd XXXX'ed out:
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<login>
<clID>REG-XXXXXXX</clID>
<pw>XXXXXXXX</pw>
<options>
<version>1.0</version>
<lang>en</lang>
</options>
<svcs>
<objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
<objURI>urn:ietf:params:xml:ns:contact-1.0</objURI>
<svcExtension>
<extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
</svcExtension>
</svcs>
</login>
</command>
</epp>
Reply==>
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><response><result
code="1000"><msg>Command completed
successfully</msg></result><trID><svTRID>ReqID-0002778173</svTRID></trID></response></epp>
Please note - the current EPP XML works for the COZA System, Cocca and Central-NIC.
Hello Mark
We don't abbreviate XML's namespaces, etc. So we send "full version",
which in your case would be
<?xml version="1.0" encoding="utf-8"
standalone="no"?><epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd"><command><info><domain:info
xmlns:domain="http://www.nic.cz/xml/epp/domain-1.4"
xsi:schemaLocation="http://www.nic.cz/xml/epp/domain-1.4
domain-1.4.xsd"><domain:name>dnssec.or.tz</domain:name>
</domain:info>
</info>
<clTRID>ydpg002#15-03-09at16:23:08</clTRID>
</command>
</epp>
It may seem odd to some people, but I always recommend taking a look at fred-client -v3
(extremely
verbose), to see the actual XML being sent.
Hope that helps.
Best regards
Piotr