Re: Comments on lcup-05

This is a cryptographically signed message in MIME format.

--------------ms090704080600070900010408
Content-Type: multipart/alternative;
 boundary="------------050800030305040404000603"

This is a multi-part message in MIME format.
--------------050800030305040404000603
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for your comments John.

John McMeeking wrote:

>Here's some comments on draft-ietf-ldup-lcup-05.txt:
>
>1. Overview - paragraph on state information.  I would resatate this
>something like: "... the server does not need to maintain state information
>specific to individual clients.  The server may need to maintain additional
>state information about deleted or moved/renamed entries."
>
Here is the text I decided to use, which is very similar to yours:
"... the server does not need to maintain state information specific to 
individual clients.  The server may need to maintain additional state 
information about attribute modifications, deleted entries, and 
moved/renamed entries."

>3.5 (all controls).  All these controls have a significant number of
>optional fields.  I think we should add tags to simplify proper decoding of
>the control data.  Also, given recent discussions about ASN.1 tagging, it
>would be appropriate to state that implicit tagging is used (if it is).
>
Could you (or someone else) give me an example of what the ASN.1 should 
look like?

>4.2.7 Result for Entries that have left the result set.  There are two "An
>entry SHOULD be returned as having left...." clauses.  It appears the
>second one is left over from a rewrite, as it repeats information in 4.2.5.
>This would make it more consistent with 4.2.6.
>
Done.

>4.3.4/4.3.5.  I think the server should be given the option of rejecting a
>LCUP search that includes virtual or collective attributes.  If a server
>would normally return these attributes, it must either properly synchronize
>these attributes or reject the search request.  Maybe a new
>"lcupInvalidAttribute" or "unwillingToPerform" resultCode would be
>appropriate.
>
Here is the new text of 4.3.4 and 4.3.5:

4.3.4 Operational Attributes and Administrative Entries

An operational attribute SHOULD be returned if it is specified in the 
attributes list and would normally be returned as subject to the 
constraints of [RFC2251 Section 4.5].  If the server does not support 
syncing of operational attributes, the server MUST return a 
SearchResultDone message with a resultCode of unwillingToPerform.

LDAP Subentries [SUBENTRY] SHOULD be returned if they would normally be 
returned by the search request.  If the server does not support syncing 
of LDAP Subentries, and the server can determine from the search request 
that the client has requested LDAP Subentries to be returned (e.g. 
search control or search filter), the server MUST return a 
SearchResultDone message with a resultCode of unwillingToPerform.  
Otherwise, the server MAY simply omit returning LDAP Subentries.

4.3.5 Virtual Attributes 

An entry may have attributes whose presence in the entry, or presence of 
values of the attribute, is generated on the fly, possibly by some 
mechanism outside of the entry, elsewhere in the DIT.  An example of 
this is collective attributes [COLLECTIVE].  These attributes shall be 
referred to in this document as virtual attributes.

LCUP treats these attributes the same way as normal, non-virtual 
attributes.  A virtual attribute SHOULD be returned if it is specified 
in the attributes list and would normally be returned as subject to the 
constraints of [RFC2251 Section 4.5].  If the server does not support 
syncing of virtual attributes, the server MUST return a SearchResultDone 
message with a resultCode of unwillingToPerform. 

One consequence of this is that if you change the definition of a 
virtual attribute such that it makes the value of that attribute change 
in many entries in the client's search scope, this means that a server 
may have to return many entries to the client as a result of that one 
change.  It is not anticipated that this will be a frequent occurrence, 
and the server has the option to simply force the client to resync if 
necessary.

It is also possible that a future LDAP control will allow the client to 
request only virtual or only non-virtual attributes.

>4.4.1 Server Initiated Termination.  This para references a
>lcupClientDisconnected resultCode.  I didn't see that resultCode defined.
>
Changed to "canceled [CANCEL]".

>4.5  <What to do about this section????>  This can probably be deleted,
>though it might be helpful earlier to explain what the synchronize and
>persist phases do and the sequence of requests/controls.
>
I would like to get rid of this, or at least not require this section 
for Last Call.

>John  McMeeking
>
>  
>

--------------050800030305040404000603
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Thanks for your comments John.<br>
<br>
John McMeeking wrote:<br>
<blockquote type="cite"
 cite="midOFEE973863.406DB101-ON86256D3D.006BC4D8-86256D3D.006DEC9D@us.ibm.com">
  <pre wrap="">Here's some comments on draft-ietf-ldup-lcup-05.txt:

1. Overview - paragraph on state information.  I would resatate this
something like: "... the server does not need to maintain state information
specific to individual clients.  The server may need to maintain additional
state information about deleted or moved/renamed entries."</pre>
</blockquote>
Here is the text I decided to use, which is very similar to yours:<br>
"... <span style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;">the
server does not need to maintain state information
specific to individual clients.<span style="">&nbsp; </span>The
server may need to maintain additional state information about
attribute
modifications, deleted entries, and moved/renamed entries."</span>
<blockquote type="cite"
 cite="midOFEE973863.406DB101-ON86256D3D.006BC4D8-86256D3D.006DEC9D@us.ibm.com">
  <pre wrap="">3.5 (all controls).  All these controls have a significant number of
optional fields.  I think we should add tags to simplify proper decoding of
the control data.  Also, given recent discussions about ASN.1 tagging, it
would be appropriate to state that implicit tagging is used (if it is).</pre>
</blockquote>
Could you (or someone else) give me an example of what the ASN.1 should
look like?<br>
<blockquote type="cite"
 cite="midOFEE973863.406DB101-ON86256D3D.006BC4D8-86256D3D.006DEC9D@us.ibm.com">
  <pre wrap="">4.2.7 Result for Entries that have left the result set.  There are two "An
entry SHOULD be returned as having left...." clauses.  It appears the
second one is left over from a rewrite, as it repeats information in 4.2.5.
This would make it more consistent with 4.2.6.</pre>
</blockquote>
Done.<br>
<blockquote type="cite"
 cite="midOFEE973863.406DB101-ON86256D3D.006BC4D8-86256D3D.006DEC9D@us.ibm.com">
  <pre wrap="">4.3.4/4.3.5.  I think the server should be given the option of rejecting a
LCUP search that includes virtual or collective attributes.  If a server
would normally return these attributes, it must either properly synchronize
these attributes or reject the search request.  Maybe a new
"lcupInvalidAttribute" or "unwillingToPerform" resultCode would be
appropriate.</pre>
</blockquote>
Here is the new text of 4.3.4 and 4.3.5:<br>
<p class="RFCHeading3"><!--[if !supportLists]-->4.3.4 Operational
Attributes and Administrative Entries</p>
<p class="RFCText" style="margin-left: 0in;"><!--[if !supportEmptyParas]--><!--[endif]--><o:p></o:p></p>
<p class="RFCText">An operational attribute SHOULD be returned if it is
specified
in the attributes list and would normally be returned as subject to the
constraints of [RFC2251 Section 4.5].<span style="">&nbsp;
</span>If the server does not support syncing of operational
attributes, the
server MUST return a SearchResultDone message with a resultCode of
unwillingToPerform.</p>
<p class="RFCText" style="margin-left: 0in;"><!--[if !supportEmptyParas]--><!--[endif]--><o:p></o:p></p>
<p class="RFCText">LDAP Subentries [SUBENTRY] SHOULD be returned if
they would
normally be returned by the search request.<span style="">&nbsp;
</span>If the server does not support syncing of LDAP Subentries, and
the
server can determine from the search request that the client has
requested LDAP
Subentries to be returned (e.g. search control or search filter), the
server
MUST return a SearchResultDone message with a resultCode of
unwillingToPerform.<span style="">&nbsp; </span>Otherwise, the server MAY
simply omit
returning LDAP Subentries.</p>
<p class="RFCText" style="margin-left: 0in;"><!--[if !supportEmptyParas]--><!--[endif]--><o:p></o:p></p>
<p class="RFCText" style="margin-left: 0in;"><!--[if !supportLists]-->4.3.5
Virtual
Attributes&nbsp;<!--[endif]--><o:p></o:p></p>
<p class="RFCText">An entry may have attributes whose presence in the
entry, or
presence of values of the attribute, is generated on the fly, possibly
by some
mechanism outside of the entry, elsewhere in the DIT.<span style="">&nbsp; </span>An
example of this is collective attributes [COLLECTIVE].<span style="">&nbsp; </span>These
attributes shall be referred to in
this document as virtual attributes.</p>
<p class="RFCText"><!--[if !supportEmptyParas]--><!--[endif]--><o:p></o:p></p>
<p class="RFCText">LCUP treats these attributes the same way as normal,
non-virtual
attributes.<span style="">&nbsp; </span>A virtual attribute SHOULD
be returned if it is specified in the attributes list and would
normally be
returned as subject to the constraints of [RFC2251 Section 4.5].<span
 style="">&nbsp; </span>If the server does not support syncing of virtual
attributes, the server MUST return a SearchResultDone message with a
resultCode
of unwillingToPerform.&nbsp;<!--[endif]--><o:p></o:p></p>
<p class="RFCText">One consequence of this is that if you change the
definition
of a virtual attribute such that it makes the value of that attribute
change in
many entries in the client's search scope, this means that a server may
have to
return many entries to the client as a result of that one change.<span
 style="">&nbsp; </span>It is not anticipated that this will be a
frequent occurrence, and the server has the option to simply force the
client
to resync if necessary.</p>
<p class="RFCText"><!--[if !supportEmptyParas]--><!--[endif]--> It is
also possible that a future LDAP control will allow the client
to request only virtual or only non-virtual attributes.</p>
<blockquote type="cite"
 cite="midOFEE973863.406DB101-ON86256D3D.006BC4D8-86256D3D.006DEC9D@us.ibm.com">
  <pre wrap="">4.4.1 Server Initiated Termination.  This para references a
lcupClientDisconnected resultCode.  I didn't see that resultCode defined.</pre>
</blockquote>
Changed to "canceled [CANCEL]".<br>
<blockquote type="cite"
 cite="midOFEE973863.406DB101-ON86256D3D.006BC4D8-86256D3D.006DEC9D@us.ibm.com">
  <pre wrap="">4.5  &lt;What to do about this section????&gt;  This can probably be deleted,
though it might be helpful earlier to explain what the synchronize and
persist phases do and the sequence of requests/controls.</pre>
</blockquote>
I would like to get rid of this, or at least not require this section
for Last Call.<br>
<blockquote type="cite"
 cite="midOFEE973863.406DB101-ON86256D3D.006BC4D8-86256D3D.006DEC9D@us.ibm.com">
  <pre wrap="">John  McMeeking

  </pre>
</blockquote>
</body>
</html>

--------------050800030305040404000603--

--------------ms090704080600070900010408
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL6zCC
A9YwggM/oAMCAQICBAIAAeYwDQYJKoZIhvcNAQEFBQAwRTELMAkGA1UEBhMCVVMxGDAWBgNV
BAoTD0dURSBDb3Jwb3JhdGlvbjEcMBoGA1UEAxMTR1RFIEN5YmVyVHJ1c3QgUm9vdDAeFw0w
MTA2MDExMjQ3MDBaFw0wNDA2MDEyMzU5MDBaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
Q0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIElu
YzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlm
aWNhdGUgQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi718sdkOJSxpf
s+X4qm+LL4FNZ/+9Sg9jLsTchfaeLEkmIP8AF+SIiGne/YNX4KMRGRGq1ty877PSFS5Uxm58
v9m5w0bTCQWE5VNcSO2EhZoOOz0WB1zws3mrmhClvMGk0XhMBuVkQfwFJWMm6+8Mx25UoYzO
VFe2H5LashJLjQIDAQABo4IBgjCCAX4wTQYDVR0fBEYwRDBCoECgPoY8aHR0cDovL3d3dzEu
dXMtaG9zdGluZy5iYWx0aW1vcmUuY29tL2NnaS1iaW4vQ1JML0dURVJvb3QuY2dpMB0GA1Ud
DgQWBBQp27Itg35/iyO7wsxmuTnoKfMChjBmBgNVHSAEXzBdMEYGCiqGSIb4YwECAQUwODA2
BggrBgEFBQcCARYqaHR0cDovL3d3dy5iYWx0aW1vcmUuY29tL0NQUy9PbW5pUm9vdC5odG1s
MBMGAyoDBDAMMAoGCCsGAQUFBwIBMFgGA1UdIwRRME+hSaRHMEUxCzAJBgNVBAYTAlVTMRgw
FgYDVQQKEw9HVEUgQ29ycG9yYXRpb24xHDAaBgNVBAMTE0dURSBDeWJlclRydXN0IFJvb3SC
AgGjMCsGA1UdEAQkMCKADzIwMDEwNjAxMTI0NzMwWoEPMjAwMzA5MDEyMzU5MDBaMA4GA1Ud
DwEB/wQEAwIBBjAPBgNVHRMECDAGAQH/AgEBMA0GCSqGSIb3DQEBBQUAA4GBAEpiDtn6RncE
CmwN3f7SIjmZEAquiC2GPVeE5hIkN2n7WV7iEbD5n6RXhoppHwZj0X3uMzZJECAPH5cXLCds
PWw5BHviReiHG1S2YEFtHa4F8535OjSa43trTHH466grg7A1kEwZaHHt8GMiXsJb7CB6tbBR
c+kH7oFndnlT95XUMIIEBDCCA22gAwIBAgICb4cwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMS
QW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQD
Ex5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDMwNzE3MTI0MjU4WhcNMDQw
MTEzMTI0MjU4WjB9MQswCQYDVQQGEwJVUzEbMBkGA1UEChMSQW1lcmljYSBPbmxpbmUgSW5j
MRUwEwYKCZImiZPyLGQBARMFcmljaG0xITAfBgkqhkiG9w0BCQEWEnJpY2htQG5ldHNjYXBl
LmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5zb24wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBAM0xzJVFg2ipLH24lRTenspJ6r43StzZDCOzysfywnc6TkwnkHI2ZXJ/2NUa5nfUMVL0
wrajB6evmyIb5Q81HC3IqHB7ltCQcU+jwTgl5QvhdGj5FTGYTV6SxyLrWfTXsFObq9oONdwl
+egskUTRKY/DqzfooL1oaLfdreKcBmvBAgMBAAGjggF6MIIBdjAOBgNVHQ8BAf8EBAMCBSAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGCWCGSAGG+EIBDQQ2FjRJc3N1ZWQg
YnkgTmV0c2NhcGUgQ2VydGlmaWNhdGUgTWFuYWdlbWVudCBTeXN0ZW0gNC41MIGbBgNVHREE
gZMwgZCBEnJpY2htQG5ldHNjYXBlLmNvbYEOcmljaG1AbWNvbS5jb22BF3JpY2hfbWVnZ2lu
c29uQG1jb20uY29tgRtyaWNoX21lZ2dpbnNvbkBuZXRzY2FwZS5jb22BG3JtZWdnaW5zb24w
MjI0QG5ldHNjYXBlLmNvbYEXcm1lZ2dpbnNvbjAyMjRAbWNvbS5jb20wHwYDVR0jBBgwFoAU
KduyLYN+f4sju8LMZrk56CnzAoYwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRw
Oi8vY2VydGlmaWNhdGVzLm5ldHNjYXBlLmNvbS9vY3NwMA0GCSqGSIb3DQEBBQUAA4GBAH1a
Cx0wGJLNPmAQp2GaSV+ICOvOn2capnZr5q1h63Wm+NS4lVK7liHoXjxbDNLPTcXmzUVXmcpg
gP5yT25Pueb/rUoVR4UOOt9MUf0vAOqR849VYzRSvLtks1oI3e51S0EgM20f7FwF1ec1a7Fa
buMyteo6vMEZlet5mCWVO1o+MIIEBTCCA26gAwIBAgICb4gwDQYJKoZIhvcNAQEEBQAwgZMx
CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkG
A1UEChMSQW1lcmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScw
JQYDVQQDEx5JbnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDMwNzE3MTI0MjU4
WhcNMDQwMTEzMTI0MjU4WjB9MQswCQYDVQQGEwJVUzEbMBkGA1UEChMSQW1lcmljYSBPbmxp
bmUgSW5jMRUwEwYKCZImiZPyLGQBARMFcmljaG0xITAfBgkqhkiG9w0BCQEWEnJpY2htQG5l
dHNjYXBlLmNvbTEXMBUGA1UEAxMOUmljaCBNZWdnaW5zb24wgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAMxIyDbN22w/X3RLlXYEzqbSJtCxFwKBdAAyTIyasbUm4TnKdjpUfcf0cUN/
eD/zuItQ8wYqOosRQwXqKd6BtS/AL6kSjBDQhizXCzLbhoL4dWF4inxYgX3S26RenSGm+PZM
uU93PvmosYjcwwSawd4cYyOS/bwydDR44l5zm4i9AgMBAAGjggF7MIIBdzAPBgNVHQ8BAf8E
BQMDB4AAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBglghkgBhvhCAQ0ENhY0
SXNzdWVkIGJ5IE5ldHNjYXBlIENlcnRpZmljYXRlIE1hbmFnZW1lbnQgU3lzdGVtIDQuNTCB
mwYDVR0RBIGTMIGQgRJyaWNobUBuZXRzY2FwZS5jb22BDnJpY2htQG1jb20uY29tgRdyaWNo
X21lZ2dpbnNvbkBtY29tLmNvbYEbcmljaF9tZWdnaW5zb25AbmV0c2NhcGUuY29tgRtybWVn
Z2luc29uMDIyNEBuZXRzY2FwZS5jb22BF3JtZWdnaW5zb24wMjI0QG1jb20uY29tMB8GA1Ud
IwQYMBaAFCnbsi2Dfn+LI7vCzGa5Oegp8wKGMEEGCCsGAQUFBwEBBDUwMzAxBggrBgEFBQcw
AYYlaHR0cDovL2NlcnRpZmljYXRlcy5uZXRzY2FwZS5jb20vb2NzcDANBgkqhkiG9w0BAQQF
AAOBgQCs46Yi7zWvrRr02pvEVb5SRaOmYgUsydv4aUPQlHO3rx3e2e9Uc0rV1l0JNfcRGhGW
Kwt/RjbbXDVwEf7Fzi0eRyRuV+ffKHzkDcvE+AN8CldvociUFH3nJXGtAIIdbKOmCMkPkK8b
HXZ1M4+H8aCBQLriyq/b99gK11VeeFcifjGCA1QwggNQAgEBMIGaMIGTMQswCQYDVQQGEwJV
UzELMAkGA1UECBMCQ0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJp
Y2EgT25saW5lIEluYzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50
cmFuZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgJviDAJBgUrDgMCGgUAoIICDzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA3MjMyMDI5MTBaMCMGCSqG
SIb3DQEJBDEWBBTMulBCgZS/NMaXtG1QO0FM78bq3jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCBqwYJKwYBBAGCNxAEMYGdMIGaMIGTMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
Q0ExFjAUBgNVBAcTDU1vdW50YWluIFZpZXcxGzAZBgNVBAoTEkFtZXJpY2EgT25saW5lIElu
YzEZMBcGA1UECxMQQU9MIFRlY2hub2xvZ2llczEnMCUGA1UEAxMeSW50cmFuZXQgQ2VydGlm
aWNhdGUgQXV0aG9yaXR5AgJvhzCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZMxCzAJBgNVBAYT
AlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEbMBkGA1UEChMSQW1l
cmljYSBPbmxpbmUgSW5jMRkwFwYDVQQLExBBT0wgVGVjaG5vbG9naWVzMScwJQYDVQQDEx5J
bnRyYW5ldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCAm+HMA0GCSqGSIb3DQEBAQUABIGAGtaD
PUEaQpN9BpxRVSJdxRRhMOqvz9NQWa2HuW8mBlfFZf0xyN0JTm83VEEL9LzUkRzpCviOufuV
crmVfzSkKQDE3dbQ2HQNg1tMPJMYcTZ8jruDXcMoDnbHBN8LD6fOTWzTi28mStQEqur6pr2D
YSCJCffNtB01nVNMaHbitUwAAAAAAAA=
--------------ms090704080600070900010408--