Re: New Version Notification for draft-brown-epp-fees-01.txt

--===============4753820584540516352==
Content-Type: multipart/alternative; boundary=047d7b10c99194037204f86d3dd7

--047d7b10c99194037204f86d3dd7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think this could be modeled by having extensible custom types on each "
*fee"* element, or maybe on each "*cd"* element. I would be hesitant to
embed too much application logic into the protocol, and instead just make
the schema flexible enough to model different scenarios.


On Thu, May 1, 2014 at 3:05 PM, Luis Mu=F1oz <[email protected]> wrote:

>
> On May 1, 2014, at 11:52 AM, MICHAEL W YOUNG <[email protected]> wrote:
>
> > It would be interesting to query a given domain for an answer on which
> programs its applicable for.  Lets say I am a registrar that signed up fo=
r
> marketing programs (out of registry band) "A1" and program "B2" with the
> registry operator, instead of keeping track of that in my registrar
> systems, whenever I go to check pricing on a domain, I would also receive
> any current programs that are applicable to that domain along with the ba=
se
> pricing I originally queried.  I can then do subsequent lookups on the
> program pricing if I don't have the program pricing handy, or if the
> program pricing varies depending on the specific string.
>
> Why not return the pricing associated to each program in the same
> transaction? That would save on queries and I think it's a fair assumptio=
n
> that server-side looking up the list of programs will also provide the
> relevant pricing information with the same effort.
>
> Best regards
>
> -lem
>
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg
>

--047d7b10c99194037204f86d3dd7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think this could be modeled by having extensible custom =
types on each &quot;<b>fee&quot;</b> element, or maybe on each &quot;<b>cd&=
quot;</b> element. I would be hesitant to embed too much application logic =
into the protocol, and instead just make the schema flexible enough to mode=
l different scenarios.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, May 1=
, 2014 at 3:05 PM, Luis Mu=F1oz <span dir=3D"ltr">&lt;<a href=3D"mailto:lem=
@isc.org" target=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div class=3D""><br>
On May 1, 2014, at 11:52 AM, MICHAEL W YOUNG &lt;<a href=3D"mailto:michael@=
mwyoung.ca">[email protected]</a>&gt; wrote:<br>
<br>
&gt; It would be interesting to query a given domain for an answer on which=
 programs its applicable for. =A0Lets say I am a registrar that signed up f=
or marketing programs (out of registry band) &quot;A1&quot; and program &qu=
ot;B2&quot; with the registry operator, instead of keeping track of that in=
 my registrar systems, whenever I go to check pricing on a domain, I would =
also receive any current programs that are applicable to that domain along =
with the base pricing I originally queried. =A0I can then do subsequent loo=
kups on the program pricing if I don&#39;t have the program pricing handy, =
or if the program pricing varies depending on the specific string.<br>

<br>
</div>Why not return the pricing associated to each program in the same tra=
nsaction? That would save on queries and I think it&#39;s a fair assumption=
 that server-side looking up the list of programs will also provide the rel=
evant pricing information with the same effort.<br>

<br>
Best regards<br>
<br>
-lem<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
provreg mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/provreg" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/provreg</a><br>
</div></div></blockquote></div><br></div>

--047d7b10c99194037204f86d3dd7--


--===============4753820584540516352==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg

--===============4753820584540516352==--