Re: Stateless vs. Stateful

At 11:04 AM -0400 7/29/02, Hollenbeck, Scott wrote:
>With email, for example, a transport mapping could be written to say that
>all of the needed commands must be sent in one message/session.

One issue is the means of authentication.  Since I'm a chair, I'll 
sit back and listen to comments on this in lieu of speaking my mind. 
(Unless I am urged to do so.)

--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

RE: Stateless vs. Stateful

> At 11:04 AM -0400 7/29/02, Hollenbeck, Scott wrote:
> >With email, for example, a transport mapping could be 
> written to say that
> >all of the needed commands must be sent in one message/session.
> 
> One issue is the means of authentication.  Since I'm a chair, I'll 
> sit back and listen to comments on this in lieu of speaking my mind. 
> (Unless I am urged to do so.)

That issue could be addressed by requiring a <login> command as the first
command in the batch.  The "session" could then be ended with either an
explicit <logout> command or reaching the end of the batch.  Additional
authentication services could be provided with either PGP or S/MIME signing
of the batch, but that's getting ahead into the specifics of an email
transport.

-Scott-

Re: I-D on Uniform Treatment of Pending Action Notification in EPP

I can not fully evalue Scott's proposal untill it is presented in a formal way

with all its implications on epp document and all associated object mapping
documents. I can only express opinion about the direction he is taking for
handling 'Pending Action Notification'.

I think a good and comprehensive example for handling 'Pending Action' can be
found in <transfer> command.  It make sense to solve any 'Pending Action'
situation in a manner similiar to <transfer> (to a reasonable extent). What I
can see from Scott's proposal he is making steps in that direction.

Regards,

Janusz

"Hollenbeck, Scott" wrote:

> > When I wrote the draft at the beginning, I was actually
> > thinking exactly
> > your way since the pending action is performed on a specific
> > object mapping.
> > But after I finished the writing, I realized that I have to
> > add <paData> to
> > every object mapping (i.e., domain, contact, and host) that
> > may need this
> > feature. The advantage for doing so, as you explained, is
> > that more object
> > specific information can be added in. The downside is that
> > <paData> will
> > have to be defined in every object mapping (existing and

Proposed Document Changes

The message was orinally sent from another account so I have to send it
again.

I would like to say a few words in defence of <status> command. Unlike
some other participants of the thread I see value in retaining the
command. It was said in the discussion that transform commands can be
resubmitted or their results can be determined by <info> command.
Retransmitting some commands could be risky (let's take <renew> for
example). Using <info> command to determine the state of the object may
not be easy.  If a registrar enforces uniquenes of clTRID <status>
command provides a convenient way of handling failure situations.

Regards,

Janusz

RE: Proposed Document Changes

> I would like to say a few words in defence of <status> command. Unlike
> some other participants of the thread I see value in retaining the
> command. It was said in the discussion that transform commands can be
> resubmitted or their results can be determined by <info> command.
> Retransmitting some commands could be risky (let's take <renew> for
> example).

There's no risk at all because all of the transform commands are idempotent.
If you send the exact same <renew> command and the first command "took" but
the response was "lost", the second command _should_ fail because the value
of the <curExpDate> element will contain the value from before the first
command succeeded.  If it doesn't fail the server is doing something wrong.

> Using <info> command to determine the state of the 
> object may not be easy.

Please explain why.  The <info> command exists explicitly to determine the
state of an object.  Even if it _is_ hard for a client to compare the
current state with what they think the state should be, there is no harm or
risk in retrying a command to be sure it "took".

> If a registrar enforces uniquenes of clTRID <status>
> command provides a convenient way of handling failure situations.

That's the subjective part. 

-Scott-

Re: Proposed Document Changes

In a way you are right about <renew> command. Right now <renew> is defined for
domains only and <curExpDate> ensures that the next <renew> command should
fail. But it is object extension (domain) specific.

Why using <info> may not be easy?
Any automatic processing based on <info> command will be object and  command
specific or it will based on the last modification date. Since last
modification date in <info> response is defined in object mapping document
using last modifification date makes such processing still object and command
dependant. Besides it requires perfect time synchronization between client and
server for any transform command for any object. That's why I added the
subjective part to my original opinion.

Regards,

Janusz

"Hollenbeck, Scott" wrote:

> > I would like to say a few words in defence of <status> command. Unlike
> > some other participants of the thread I see value in retaining the
> > command. It was said in the discussion that transform commands can be
> > resubmitted or their results can be determined by <info> command.
> > Retransmitting some commands could be risky (let's take <renew> for
> > example).
>
> There's no risk at all because all of the transform commands are idempotent.
> If you send the exact same <renew> command and the first command "took" but
> the response was "lost", the second command _should_ fail because the value
> of the <curExpDate> element will contain the value from before the first

Re: Proposed Document Changes

A few more words regarding resubmitting transform commands in case of unknown
result of the first command. If the result of the original comand is unknown and
the same command is resubmitted and returns error we may still not know the
result of the original request. If we take <renew> as an example the fact that
the second command returned an error is not sufficient for an automated process
to make a decision whether submit it again or not. A more sophisticated process
(object and method specific) is required to make such a decision.

Regards,

Janusz

janusz sienkiewicz wrote:

> In a way you are right about <renew> command. Right now <renew> is defined for
> domains only and <curExpDate> ensures that the next <renew> command should
> fail. But it is object extension (domain) specific.
>
> Why using <info> may not be easy?
> Any automatic processing based on <info> command will be object and  command
> specific or it will based on the last modification date. Since last
> modification date in <info> response is defined in object mapping document
> using last modifification date makes such processing still object and command
> dependant. Besides it requires perfect time synchronization between client and
> server for any transform command for any object. That's why I added the
> subjective part to my original opinion.
>
> Regards,
>
> Janusz

RE: Proposed Document Changes

> A few more words regarding resubmitting transform commands in 
> case of unknown
> result of the first command. If the result of the original 
> comand is unknown and
> the same command is resubmitted and returns error we may 
> still not know the
> result of the original request. If we take <renew> as an 
> example the fact that
> the second command returned an error is not sufficient for an 
> automated process
> to make a decision whether submit it again or not. A more 
> sophisticated process
> (object and method specific) is required to make such a decision.

If you consider parsing of the response to an <info> command and doing some
comparisons sophisticated, you may be right -- but that's not the point.

All the <status> command does/did was confirm that a command was received
and processed.  It does _not_ tell you if the command succeeded or failed --
that's what responses are for, and that's why the necessity of the command
has been questioned.

Now, this might lead us back to the "well, what if a response is lost"
argument?  That's why we have reliable transports, transaction identifiers,
query commands, and idempotent transform commands.

-Scott-

FW: BCP 59, RFC 3349 on A Transient Prefix for Identifying Profil es under Development by the Working Groups of the Internet Engineering Ta sk Force

Being BEEP-related, this might be of interest to folks looking at the BEEP
transport I-D.

-Scott-

-----Original Message-----
From: rfc-editor <at> rfc-editor.org [mailto:rfc-editor <at> rfc-editor.org] 
Sent: Thursday, August 01, 2002 5:44 PM
To: rfc-dist <at> rfc-editor.org
Cc: rfc-editor <at> rfc-editor.org
Subject: [rfc-dist] BCP 59, RFC 3349 on A Transient Prefix for
Identifying Profiles under Development by the Working Groups of the
Internet Engineering Task Force

A new Request for Comments is now available in online RFC libraries.

        BCP 59
        RFC 3349

        Title:	    A Transient Prefix for Identifying Profiles under
                    Development by the Working Groups of the Internet
                    Engineering Task Force 
        Author(s):  M. Rose
        Status:	    Best Current Practice
	Date:       July 2002
        Mailbox:    mrose <at> dbc.mtview.ca.us
        Pages:      6
        Characters: 7916
        SeeAlso:    BCP 59

Re: Proposed Document Changes

Defending <status> command I assumed wrong interpretation of the command
description. My intepretation was (assuming uniquness of clTRID):

Response with empty <status> - command not processed
Response with positive ack attribute - command processed, success
Response with negative ack attribute - command processed, failure

That was the only interpretation, I could figure out, that was making the
command usefull. After your clarification I agree that there is not much value
in keeping the command.

Regards,

Janusz

"Hollenbeck, Scott" wrote:

> > A few more words regarding resubmitting transform commands in
> > case of unknown
> > result of the first command. If the result of the original
> > comand is unknown and
> > the same command is resubmitted and returns error we may
> > still not know the
> > result of the original request. If we take <renew> as an
> > example the fact that
> > the second command returned an error is not sufficient for an
> > automated process
> > to make a decision whether submit it again or not. A more
> > sophisticated process
> > (object and method specific) is required to make such a decision.