![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Hi Johan, > ---------- > From: Johan Otterstrvm[SMTP:jo at sectra.se] > Sent: Wednesday, April 22, 1998 2:24 PM > To: cat-ietf at mit.edu > Subject: Bad_Target_Names > > Hello, > > I have been implementing parts of the IDUP API and I have a few > comments/questions about the specification: > > In chapter 2.3.2.2 the Target_Info parameter bundle is described. The > bundle has a set of target names, the number of bad targets and a > Bad_Target_Name. Shouldn't this be a set of Bad_Target_Name? The > discussion in the following chapter heads in that direction. It might be > possible to make the parameter bundle Bad_Target_Name to contain all the > bad names but I suppose that each name could have a different status > code. > You're right: it should be "SET OF Bad_Target_Name". Thanks for catching this! [Looks like there will be one last update to this draft after all...] > In chapter 2.3.2.3 the status code IDUP_S_MORE_OUTBUFFER_NEEDED is valid > for all the SE calls, but what is expected if the single operations gets > a buffer that is to small? Will the operation fail or should it be > possible to call it again to get the rest of the data? I suppose that > the first alternative is the better one and thus the no data is returned > and the call must be made once more with a larger buffer. > The wording of the status code description (the table in Section 1.2.1) uses the phrase "remaining data". The intention here is that the operation does not fail, but the caller only gets back whatever data will hold in the (too small) buffer and needs to keep calling (until GSS_S_COMPLETE) to get successive portions of the output data. > Is there any work going on with the c-bindings document? Version 0.3 is > not very up to date... > I am currently unaware of anyone working on the C-bindings document (though I'd love to hear from any volunteers!). -------------------------------------------- Carlisle Adams Entrust Technologies cadams at entrust.com --------------------------------------------
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.