Dear Benjamin,
Please see my feedbacks below.
Regards,
Linlin
Linlin Zhou
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > Section 4.3
> >
> > The status of the organization object after returning this response
> > MUST include "pendingCreate". The server operator reviews the
> > request offline, and informs the client of the outcome of the review
> > either by queuing a service message for retrieval via the <poll>
> > command or by using an out-of-band mechanism to inform the client of
> > the request.
> >
> > I don't think the "either" is appropriate; the earlier text *requires* the
> > service message, and allows for additional optional notification
> > mechanisms.
> > [Linlin] This <poll>mechanism is supported in section 2.9.2.3 of RFC5730.
> > So this is a easy and convinient way to inform the clients.
>
> I'm saying that the choice for the server is not "do X or do Y", it's: "do
> X, then either do Y or don't do Y". The word "either" here implies that it
> is sometimes acceptable to not do X (where X is the queuing of the service
> message).
> [Linlin] In my understanding, I think the text means do X or do Y. You can
> have two choices to inform the result by <poll> of EPP command or by
> out-of-band actions. The following <poll> response is an example using <poll>
> mechanism. Of course you can also send an email to to contact of the
> organization.
> The text is consistent with EPP RFCs. Maybe we can ask the author to confirm:)
>
Perhaps I am misreading, but I see this text in Section 4.2 that says that
the server MUST always send a service message to notify the client:
Once
the action has been completed, the client MUST be notified using a
service message that the action has been completed and that the
status of the object has changed. Other notification methods MAY be
used in addition to the required service message.
The text here in Section 4.3 says:
The status of the organization object after returning this response
MUST include "pendingCreate". The server operator reviews the
request offline, and informs the client of the outcome of the review
either by queuing a service message for retrieval via the <poll>
command or by using an out-of-band mechanism to inform the client of
the request.
which would allow either the service message, or an out-of-band mechanism,
or both mechanisms used together.
My issue with the document is that the document is internally inconsistent
-- in Section 4.2 it says "always do X", but Section 4.3 contradicts that
by saying "you could do X, or you could not do X and do Y instead". An
implementor has to pick whether to believe Section 4.2 or Section 4.3, and
we should not force them to make such a choice.
[Linlin] I can understand your concerns now. I think I had better propose a
thread and ask the author or other EPP experts for confirmation. Once I get the
feedback, I'll have a response. Thank you.
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
