Re: Comment on draft-arnold-scmp-02.txt

[John Stracke <[e-mail]>]

These responses make a lot clearer to me.  In particular, I hadn't realized that
this was a pre-existing protocol.

I would suggest that, rather than issuing this version as a standards-track RFC,
it may be better to issue it as an Informational and start work on a
standards-track version.

Jason Eaton wrote:

> Can you clarify on "wide-open"? If you mean that the payload is not
> specified, that was intentional.

Yes, that was the problem.

> >3.1: I'm dubious about the utility of the time-to-live field--how often
> >do you have an operation that you don't want to do at all if you can't
> >do it in N seconds? I suppose it might come up sometimes, but certainly
> >not every time--and TTL, like all these headers, is a MUST.  Further,
> >since you can't tell how long it's going to take for the message to
> >reach the server, you can't set the TTL reasonably.
>
> If the TTL to live value is not obtainable we want the option to move the
> message into batch mode.

Um...OK.  I'm not sure why you'd want to do that, though.  Can you give me a use
case, please?

It would probably be best to clarify this in the draft, which doesn't currently
mention batch mode at all.

> We don't want to specify the payload. As we use the protocol for serveral
> different payloads.

OK, understood; I just think that, if SCMP were adopted as a standard, the
payloads would have to be specified in standards documents, or you wouldn't have
any interoperability without private agreements (which don't scale, which is the
problem that standards are meant to address :-).

> >6: your HTTP mechanism uses POST, which is already the most heavily
> >overloaded method in HTTP.  You also should specify whether the SCMP
> >server would return the SCMP reply as the entity-body of the HTTP
> >response or connect back to the sender's HTTP server.
>
> Agreed. I will make this more clear. As far as overloaded POST ... ( shrug )

Yah, I probably wouldn't have mentioned that one if I hadn't been commenting on
the section already.  (Mind you, if this actually became a standard, I would
prefer to see a new method.)

> >Also, if you're using HTTP, why not run it over SSL/TLS instead of
> Ah, good question. We need to support non-repudiation. We cannot do this
> with the current implementation of SSL.

Really? SSLv3 supports client-side certificates; isn't that enough?

> Additionally we need to support a
> "static" message transport mechanism, ( like floppy disk, FTP ), we cannot
> do this with SSL.

Huh.  OK, I can see that.

> >7.1.2: it seems to me that the mechanisms described in the subsections
> >here are policy rather than protocol.
>
> Should we not specify policy?

I would think not.  You may want to make recommendations, probably in the
Security Considerations section; but my opinion is that you should not mandate
anything that does not directly relate to the protocol.  Security protocols are
fine--you can't have a policy saying "everything should be encrypted" if you
don't have a standard encryption protocol--but mandating how they are
administered is another matter.

> >7.2.1: since serialization is probably an important feature (without it,
> >you can't do pipelining), why not specify it? It'd be pretty easy:
>
> Yes we thought of supporting this. Part of the problem is that we have a
> working implementation of this here at CyberSource now.

Ah, I see.  That was not apparent when I read the draft; and, yes, that makes a
big difference.

> I know this is a business excuse, but I think with this version of the spec
> we can live without multi-part message support. Can we save it for the next
> version?

Fine.

> >store all replies indefinitely.  Second, it means that a buggy client
> >which generates the same request ID twice may submit two distinct
> >requests and think they've both been executed.
>
> A buggy client could make this assumption. Should a spec address buggy
> clients?

Yes, because they're unavoidable.  Consider a client that sends a request and
then suffers a hard disk crash; after being restored from backup, it doesn't
remember which request IDs it's sent, and sends some duplicates.

> >8.1: can this format support Unicode error messages?
>
> I don't see how the spec would not allow this.

But it doesn't support it, either.  You say that an error response is
"SCMP <error code> <error message>"; but you don't specify its MIME type or
whether it can carry charset and language parameters.

My feeling is that this may be a useful protocol, but we should

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
|[e-mail]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/