[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: "Zhang, Ning" <Ning.Zhang@Neustar.biz>
Date: Thu, 25 Jul 2002 13:37:08 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: Re: Comments on draft-ietf-provreg-epp-beep-02.txt

Darren,

Thanks for your comments. 

> 2.
>   "Fully processes?" Note that some sort of
>   answer needs to be returned for every BEEP
>   message. You might want to make this clear,
>   or perhaps it's already implicit in the 
>   description of <logout> in the other documents.

This <logout> response has been described in the EPP base spec. 

> 2.1.2 
>   Consider service "epp_beep" since EPP runs over
>   other TCP-based transports as well.
> 
>   In the example, the second L: should be I:
>
>
> 2.1.4 
>   Text "EPP" is duplicated. "Sent over the EPP EPP session"
>

We are aware of various typos and unforunately they did not get fixed in the
last draft. It will be fixed in the next draft.

>   I'm not sure you should specify that piggyback data must
>   be piggybacked. This is more an optimization than a semantic
>   difference. Perhaps "MAY be piggybacked" is better. Note that
>   some toolkits don't even tell you whether the data was
>   piggybacked or not.

You are right on this. "MAY be" is better.

> 2.1.7
>   You might want to mention what the semantics of a single EPP 
>   channel being closed without a <logout> is supposed to do.
>   Something like "this is equivalent to a <logout> with no
>   attributes or child elements." You might also want to mention
>   explicitly that it's OK to close the BEEP channel after the
>   <logout> has been fully processed, in order that resources
>   could be reclaimed.

We will make it clear on this in the next draft.

Thanks,
-Ning

Home | Date list | Subject list