Subject: Credential DELETE Operation

From: "Richards, Gareth" <[email-masked]>
Date: Tue, 17 Dec 2002 13:12:59 -0000

In the current ID, credentials are deleted using the UploadRequest.  

According to section 2.2.1:

a) If the UploadRequest contains no Credential and the UploadRequest
contains a "Delete="yes"" attribute, then the all the credentials associated
with that account are deleted. 

b) If the new credential from the UploadRequest contains no PayLoad field
and the new credential has a "Delete="yes"" attribute, then the (one and
only) "matching" credential is deleted. 

One minor point is that in the current schema the Payload is not an optional
element in the CredentialType and this appears to be required to allow the
second delete to occur.  

However, it may be simpler to implement the DELETE operation described in
Section 3.3 of the framework document with a separate DeleteRequest rather
than overloading the UploadRequest in the way described.  One possibility
would be for the DeleteRequest PDU to be either empty or contain an
CredentialSelector and optional LastModified.  If it is empty then it is a
request to delete all credential otherwise it is a request to delete a
specific credential.

This would have a number of advantages:

1) There would be no need to have a Delete attribute in the CredentialType.

2) There would be no need to have an optional Payload since the only time a
Credential can meaningfully not contain a Payload is if the Delete attribute
is set to "yes" and it is contained in an UploadRequest.

3) The UploadRequest PDU could be simplified by removing the Delete
attribute and making the Credential mandatory.  

4) The conditions on the use UploadRequest given in section 2.2.1 would be
simplified.

---

From: Dale Gustafson <[email-masked]>
Date: Tue, 17 Dec 2002 11:25:26 -0600

Hi Gareth,

I agree -- there appears to be little advantage to overloading the 
UPLOAD operation as currently described.

Beyond that, it's important to limit the possibility of unintended 
DELETE-ALL operations since recovering from that type of error would 
likely be painful.

That could be done with a command modifier.  Alternatively, it might be 
simpler to reserve a credential name that always means "all credentials" 
and use that to specify DOWNLOAD-ALL and DELETE-ALL operations.

Regards,

Dale Gustafson

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Dec 2002 12:15:37 +0000

Gareth,

I do have some sympathy with this approach, but its somewhat late
in the day (for this rev of the I-D) to be making such a bigish 
change given that we do have a working protocol (I don't think 
you're saying it doesn't work as is) and don't have text for 
the suggested change.

So I'd be against making this change right now.

During the last-call of the protocol draft (next rev hopefully today!) 
you can of course suggest this change *with specific text* that implements 
it (and I'd suggest waiting to base your text on the -05 I-D).

At that stage we can take it on board or not, depending on the usual
things...

Is that ok?

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com