To:
EPP Provreg <ietf-provreg@cafax.se>
From:
Ray.Bellis@nominet.org.uk
Date:
Wed, 24 Mar 2010 20:58:35 -0800
DKIM-Signature:
v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1269493118; x=1301029118; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[ietf -provreg]=20draft-gould-rfc4310bis-06.txt=20Submitted=20f or=20Review|Date:=20Wed,=2024=20Mar=202010=2020:58:35=20- 0800|Message-ID:=20<OF4A8CEE3C.E52D795B-ON802576F1.0018D9 88-882576F1.001B56B1@nominet.org.uk>|To:=20EPP=20Provreg =20<ietf-provreg@cafax.se>|MIME-Version:=201.0 |In-Reply-To:=20<OFFF4D1C80.209E83D8-ON802576D6.00374635- 802576D6.00384C63@nominet.org.uk>|References:=20<C79AE64E .37620%jgould@verisign.com>=20<C7AC7B88.37B22%jgould@veri sign.com>=20<OFFF4D1C80.209E83D8-ON802576D6.00374635-8025 76D6.00384C63@nominet.org.uk>; bh=O0W3LoMBFtwPZq54i3c4yzqWm1w7K/Vl5uycPNAiD8g=; b=ebVHS5d1G9RPMvQUdRvY27JkdJL01lZf9Kqqisj3nUp69WnQEO0noRqG to/IiI35hX3rEbav5SJ1Myaf2GxpGGGEbqh1xHRHyD4ops2regDvNPh78 eiaebKYlxLIOv2P;
DomainKey-Signature:
s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Subject: MIME-Version:X-Mailer:Message-ID:From:Date:X-MIMETrack: Content-Type; b=Ucfo4qPy1TOUXnuMcCm+7Bd4YkmXGK0lpaDKxUUFkhshnLYGRVZlxPo9 imRjWeH1Iy7JunSeYMJ4YffbQJSEMV2kn9zv584sTyo5oGi8fZfiwKjmv vzjrUINYeS9Fd1R;
In-Reply-To:
<OFFF4D1C80.209E83D8-ON802576D6.00374635-802576D6.00384C63@nominet.org.uk>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review
Having just discussed with Scott, I'd like to re-raise
this point that I made 26th February:
> Not being an EPP guru, what's the rationale for requiring a 2102
> error if the server doesn't support <secDNS:update urgent="1">
or
> <secDNS:maxSigLife> ?
>
> I would have thought that Postel's law should apply, otherwise a
> registrar has to have advance knowledge of which registries support
> those elements and which don't, and alter their submitted XML
> accordingly. I can't immediately see how any harm would come
from
> simply ignoring those elements.
To my mind, requiring the 2102 error in effect makes
policy - something we just said in the meeting that EPP specs should not
do. It _mandates_ a hard fail condition when those values are not
supported, when it would be _perfectly_ reasonable for a registry to ignore
the values, complete the operation anyway but also send back a <message/>
element indicating that the requested policy value was ignored.
Absent a "policy negotiation" feature in
EPP, I still believe that hard failing these options also puts too high
an implementation cost on the _client_ side of this specification. If
the server announces support for the secDNS 1.1 extension, the client shouldn't
also need additional coding/templating to handle the four possible variants
of whether the particular registry server it's talking to also supports
"maxSigLife" and/or "urgent".
Unfortunately I don't know how to address this without
requiring a larger change than the AUTH48 window permits.
There's also a couple of nits relating to <secDNS:update
urgent="..."> which I think can be easily fixed in AUTH48.
Firstly, §5.2.5 says "A server MUST return an
EPP error result code of 2102 if the "urgent" attribute is specified
and the server does not support it". I believe this is incorrect
- the "urgent" attribute is _always_ specified, since it has
a default value (i.e. "false"). Notwithstanding my comments
above about the suitability of the 2102 error in the first place, this
sentence needs to be qualified as "specified with a 'true' value".
Secondly (although it is permitted by XML Schema)
the examples might look better if they read <... urgent="true">
rather than <... urgent="1">, since the draft and schema
always use "false" rather than "0" to represent the
opposite value.
kind regards,
Ray
Home |
Date list |
Subject list