Subject: Extensibility of controlValue and Extended Operation values

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 31 Mar 2003 17:56:20 -0700

All,

There has been some recent activity on the ldapext list that is
relevant to the ldapbis list. Please see the following (and any
supporting messages in the attachment list for background) to voice your
opinion.

Jim

p.s. sorry, I should have just referenced the messages in the archive,
but I couldn't find the right archive.

<message>
Ok, it seems that group consensus is moving in favor of this kind of
wording, so let it be done. But.. my example used SHOULD, and this
example uses SHALL (MUST). MUST may break some existing
implementations.
I'm willin g to use MUST/SHALL wording if group consensus agrees.

Note also, that 5.1 in Protocol doesn't say anything about the
extensibility of the ASN.1. It only talks about the BER encoding.
Basically, I need to reconcile this between Sections 4 (Elements of
Protocol), 4.1.11 (Controls), 4.12 (Extended Operations), and 5.1
(Protocol Encoding).

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 3/31/03 8:45:56 AM >>>
At 10:47 PM 3/28/2003, Jim Sermersheim wrote:
>I'd love to do this, but the fact is, values of controls and extended
>operations are OCTET STRING types.

Yes, but as LDAP extensions are defining "LDAP protocol elements",
I think it is reasonable to say that this SHALL apply to control and
extended operation values which are described in term of ASN.1 and
encoded using BER (as described in 5.1) unless the technical
specification defining the LDAP protocol element explicitly states
otherwise.

I encourage extension authors to include to define the
term BER-encoded as follows.
   Protocol elements are described using ASN.1 [X.680].  The term
   "BER-encoded" means the element is to be encoded using the Basic
   Encoding Rules [X.690] under the restrictions detailed in
   Section 5.1 of [RFC2251].

Kurt 

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext

Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: [email-masked] (Mark C Smith)
To: [email-masked]
Cc: [email-masked]
Date: Fri, 28 Mar 2003 09:32:16 -0500
List-Id: LDAP Extension Working Group <ldapext.ietf.org>

Thank you for your helpful response.

One follow up question: in the absence of any indication, the default in 
ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension 
documents intend to use IMPLICIT (which for example is specified in 
Appendix A of RFC 2251) but that fact may not be mentioned. One example:

http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt

-Mark

Steven Legg wrote:

>Mark,
>
>Mark C Smith wrote:
>  
>
>>Someone asked me this week what the correct BER encoding is for a
>>PasswordPolicyResponseValue (from
>>
>>    
>>
>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt
>).
>  
>
>>The ASN.1 from section 5.2 of the I-D is:
>>
>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>       warning   [0] CHOICE OPTIONAL {
>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>>       error     [1] ENUMERATED OPTIONAL {
>>           passwordExpired       (0),
>>           accountLocked         (1),
>>           changeAfterReset      (2),
>>           passwordModNotAllowed (3),
>>           mustSupplyOldPassword (4),
>>           invalidPasswordSyntax (5),
>>           passwordTooShort      (6),
>>           passwordTooYoung      (7),
>>           passwordInHistory     (8) } }
>>    
>>
>
>First up, there are syntax errors in this type definition.
>It should read:
>
>    PasswordPolicyResponseValue ::= SEQUENCE {
>       warning   [0] CHOICE {
>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) } OPTIONAL,
>       error     [1] ENUMERATED {
>           passwordExpired       (0),
>           accountLocked         (1),
>           changeAfterReset      (2),
>           passwordModNotAllowed (3),
>           mustSupplyOldPassword (4),
>           invalidPasswordSyntax (5),
>           passwordTooShort      (6),
>           passwordTooYoung      (7),
>           passwordInHistory     (8) } OPTIONAL }
>
>
>  
>
>>Notice that the warning element is both OPTIONAL (with a context
>>specific tag of 0) and a CHOICE with embedded context specific tags (0
>>timeBeforeExpiration and 1 for graceLoginsRemaining).
>>Normally, a CHOICE
>>is encoded simply as whatever element as chosen, e.g., if
>>timeBeforeExpiration is chosen one would just encode an INTEGER with a
>>context specific primitive tag of 0. But the tag associated with the
>>outer element (warning) also needs to be included so the decoder can
>>tell that a warning element was included (remember, it is optional).
>>What is the right way to encode this?
>>    
>>
>
>If the tag default is IMPLICIT TAGS then the encoding is as
>you've stated above. The implicit tagging suppresses the universal tag
>of the INTEGER, but there is no universal tag (or length) for CHOICE
>and implicit tagging never applies to a CHOICE.
>
>With IMPLICIT tags the warning element, when present, is encoded as
>
>    [constructed 0] length [primitive 0] length integer-value-octets
>
>With EXPLICIT tags the warning element, when present, is encoded as
>
>    [constructed 0] length [constructed 0] length
>        [primitive UNIVERSAL 2] length integer-value-octets
>
>  
>
>>One ASN.1 compiler I used encoded the warning element as a constructed
>>element that contains one integer (which allows two tags to
>>be encoded,
>>one associated with the constructed/container element and one with the
>>integer itself). Is that the right thing to do?
>>    
>>
>
>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't say
>whether EXPLICIT or IMPLICIT tagging should apply.
>
>Regards,
>Steven
>

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: "Jim Sermersheim" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 28 Mar 2003 19:23:27 -0700
List-Id: LDAP Extension Working Group <ldapext.ietf.org>

I bet you're right. (Now where is that LDAP extensions guidelines
document...?)

>>> Mark C Smith <[email-masked]> 3/28/03 7:32:16 AM >>>
Thank you for your helpful response.

One follow up question: in the absence of any indication, the default
in 
ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension 
documents intend to use IMPLICIT (which for example is specified in 
Appendix A of RFC 2251) but that fact may not be mentioned. One
example:

http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt

-Mark

Steven Legg wrote:

>Mark,
>
>Mark C Smith wrote:
>  
>
>>Someone asked me this week what the correct BER encoding is for a
>>PasswordPolicyResponseValue (from
>>
>>    
>>
>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt

>).
>  
>
>>The ASN.1 from section 5.2 of the I-D is:
>>
>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>       warning   [0] CHOICE OPTIONAL {
>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>>       error     [1] ENUMERATED OPTIONAL {
>>           passwordExpired       (0),
>>           accountLocked         (1),
>>           changeAfterReset      (2),
>>           passwordModNotAllowed (3),
>>           mustSupplyOldPassword (4),
>>           invalidPasswordSyntax (5),
>>           passwordTooShort      (6),
>>           passwordTooYoung      (7),
>>           passwordInHistory     (8) } }
>>    
>>
>
>First up, there are syntax errors in this type definition.
>It should read:
>
>    PasswordPolicyResponseValue ::= SEQUENCE {
>       warning   [0] CHOICE {
>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
OPTIONAL,
>       error     [1] ENUMERATED {
>           passwordExpired       (0),
>           accountLocked         (1),
>           changeAfterReset      (2),
>           passwordModNotAllowed (3),
>           mustSupplyOldPassword (4),
>           invalidPasswordSyntax (5),
>           passwordTooShort      (6),
>           passwordTooYoung      (7),
>           passwordInHistory     (8) } OPTIONAL }
>
>
>  
>
>>Notice that the warning element is both OPTIONAL (with a context
>>specific tag of 0) and a CHOICE with embedded context specific tags
(0
>>timeBeforeExpiration and 1 for graceLoginsRemaining).
>>Normally, a CHOICE
>>is encoded simply as whatever element as chosen, e.g., if
>>timeBeforeExpiration is chosen one would just encode an INTEGER with
a
>>context specific primitive tag of 0. But the tag associated with the
>>outer element (warning) also needs to be included so the decoder can
>>tell that a warning element was included (remember, it is optional).
>>What is the right way to encode this?
>>    
>>
>
>If the tag default is IMPLICIT TAGS then the encoding is as
>you've stated above. The implicit tagging suppresses the universal
tag
>of the INTEGER, but there is no universal tag (or length) for CHOICE
>and implicit tagging never applies to a CHOICE.
>
>With IMPLICIT tags the warning element, when present, is encoded as
>
>    [constructed 0] length [primitive 0] length integer-value-octets
>
>With EXPLICIT tags the warning element, when present, is encoded as
>
>    [constructed 0] length [constructed 0] length
>        [primitive UNIVERSAL 2] length integer-value-octets
>
>  
>
>>One ASN.1 compiler I used encoded the warning element as a
constructed
>>element that contains one integer (which allows two tags to
>>be encoded,
>>one associated with the constructed/container element and one with
the
>>integer itself). Is that the right thing to do?
>>    
>>
>
>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't
say
>whether EXPLICIT or IMPLICIT tagging should apply.
>
>Regards,
>Steven
>

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: "Kurt D. Zeilenga" <[email-masked]>
To: "Jim Sermersheim" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 28 Mar 2003 18:39:30 -0800

At 06:23 PM 3/28/2003, Jim Sermersheim wrote:
>I bet you're right.  (Now where is that LDAP extensions guidelines
>document...?)

I can add something to draft-zeilenga-ldap-ext about this...
but maybe it *might* be appropriate to cover this in the
revision of Section 5.1 of RFC 2251.  Loosely speaking,
values of controls and extended operations are elements
of LDAP and hence subject to Section 5.1 requirements.

I suggest someone suggest some text to LDAPBIS.

Alternatively (or maybe, additionally), this can be covered
in draft-zeilenga-ldap-ext.  I'd welcome text suggestions.

Kurt

>>>> Mark C Smith <[email-masked]> 3/28/03 7:32:16 AM >>>
>Thank you for your helpful response.
>
>One follow up question: in the absence of any indication, the default
>in 
>ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension 
>documents intend to use IMPLICIT (which for example is specified in 
>Appendix A of RFC 2251) but that fact may not be mentioned. One
>example:
>
>http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt
>
>
>-Mark
>
>
>Steven Legg wrote:
>
>>Mark,
>>
>>Mark C Smith wrote:
>>  
>>
>>>Someone asked me this week what the correct BER encoding is for a
>>>PasswordPolicyResponseValue (from
>>>
>>>    
>>>
>>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt
>
>>).
>>  
>>
>>>The ASN.1 from section 5.2 of the I-D is:
>>>
>>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>>       warning   [0] CHOICE OPTIONAL {
>>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>>>       error     [1] ENUMERATED OPTIONAL {
>>>           passwordExpired       (0),
>>>           accountLocked         (1),
>>>           changeAfterReset      (2),
>>>           passwordModNotAllowed (3),
>>>           mustSupplyOldPassword (4),
>>>           invalidPasswordSyntax (5),
>>>           passwordTooShort      (6),
>>>           passwordTooYoung      (7),
>>>           passwordInHistory     (8) } }
>>>    
>>>
>>
>>First up, there are syntax errors in this type definition.
>>It should read:
>>
>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>       warning   [0] CHOICE {
>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>OPTIONAL,
>>       error     [1] ENUMERATED {
>>           passwordExpired       (0),
>>           accountLocked         (1),
>>           changeAfterReset      (2),
>>           passwordModNotAllowed (3),
>>           mustSupplyOldPassword (4),
>>           invalidPasswordSyntax (5),
>>           passwordTooShort      (6),
>>           passwordTooYoung      (7),
>>           passwordInHistory     (8) } OPTIONAL }
>>
>>
>>  
>>
>>>Notice that the warning element is both OPTIONAL (with a context
>>>specific tag of 0) and a CHOICE with embedded context specific tags
>(0
>>>timeBeforeExpiration and 1 for graceLoginsRemaining).
>>>Normally, a CHOICE
>>>is encoded simply as whatever element as chosen, e.g., if
>>>timeBeforeExpiration is chosen one would just encode an INTEGER with
>a
>>>context specific primitive tag of 0. But the tag associated with the
>>>outer element (warning) also needs to be included so the decoder can
>>>tell that a warning element was included (remember, it is optional).
>>>What is the right way to encode this?
>>>    
>>>
>>
>>If the tag default is IMPLICIT TAGS then the encoding is as
>>you've stated above. The implicit tagging suppresses the universal
>tag
>>of the INTEGER, but there is no universal tag (or length) for CHOICE
>>and implicit tagging never applies to a CHOICE.
>>
>>With IMPLICIT tags the warning element, when present, is encoded as
>>
>>    [constructed 0] length [primitive 0] length integer-value-octets
>>
>>With EXPLICIT tags the warning element, when present, is encoded as
>>
>>    [constructed 0] length [constructed 0] length
>>        [primitive UNIVERSAL 2] length integer-value-octets
>>
>>  
>>
>>>One ASN.1 compiler I used encoded the warning element as a
>constructed
>>>element that contains one integer (which allows two tags to
>>>be encoded,
>>>one associated with the constructed/container element and one with
>the
>>>integer itself). Is that the right thing to do?
>>>    
>>>
>>
>>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't
>say
>>whether EXPLICIT or IMPLICIT tagging should apply.
>>
>>Regards,
>>Steven
>>
>
>_______________________________________________
>Ldapext mailing list
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext
>_______________________________________________
>Ldapext mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ldapext

Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: "Kurt D. Zeilenga" <[email-masked]>
To: "Jim Sermersheim" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 28 Mar 2003 18:39:30 -0800
List-Id: LDAP Extension Working Group <ldapext.ietf.org>

At 06:23 PM 3/28/2003, Jim Sermersheim wrote:
>I bet you're right.  (Now where is that LDAP extensions guidelines
>document...?)

I can add something to draft-zeilenga-ldap-ext about this...
but maybe it *might* be appropriate to cover this in the
revision of Section 5.1 of RFC 2251.  Loosely speaking,
values of controls and extended operations are elements
of LDAP and hence subject to Section 5.1 requirements.

I suggest someone suggest some text to LDAPBIS.

Alternatively (or maybe, additionally), this can be covered
in draft-zeilenga-ldap-ext.  I'd welcome text suggestions.

Kurt

>>>> Mark C Smith <[email-masked]> 3/28/03 7:32:16 AM >>>
>Thank you for your helpful response.
>
>One follow up question: in the absence of any indication, the default
>in 
>ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension 
>documents intend to use IMPLICIT (which for example is specified in 
>Appendix A of RFC 2251) but that fact may not be mentioned. One
>example:
>
>http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt
>
>
>-Mark
>
>
>Steven Legg wrote:
>
>>Mark,
>>
>>Mark C Smith wrote:
>>  
>>
>>>Someone asked me this week what the correct BER encoding is for a
>>>PasswordPolicyResponseValue (from
>>>
>>>    
>>>
>>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt
>
>>).
>>  
>>
>>>The ASN.1 from section 5.2 of the I-D is:
>>>
>>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>>       warning   [0] CHOICE OPTIONAL {
>>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>>>       error     [1] ENUMERATED OPTIONAL {
>>>           passwordExpired       (0),
>>>           accountLocked         (1),
>>>           changeAfterReset      (2),
>>>           passwordModNotAllowed (3),
>>>           mustSupplyOldPassword (4),
>>>           invalidPasswordSyntax (5),
>>>           passwordTooShort      (6),
>>>           passwordTooYoung      (7),
>>>           passwordInHistory     (8) } }
>>>    
>>>
>>
>>First up, there are syntax errors in this type definition.
>>It should read:
>>
>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>       warning   [0] CHOICE {
>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>OPTIONAL,
>>       error     [1] ENUMERATED {
>>           passwordExpired       (0),
>>           accountLocked         (1),
>>           changeAfterReset      (2),
>>           passwordModNotAllowed (3),
>>           mustSupplyOldPassword (4),
>>           invalidPasswordSyntax (5),
>>           passwordTooShort      (6),
>>           passwordTooYoung      (7),
>>           passwordInHistory     (8) } OPTIONAL }
>>
>>
>>  
>>
>>>Notice that the warning element is both OPTIONAL (with a context
>>>specific tag of 0) and a CHOICE with embedded context specific tags
>(0
>>>timeBeforeExpiration and 1 for graceLoginsRemaining).
>>>Normally, a CHOICE
>>>is encoded simply as whatever element as chosen, e.g., if
>>>timeBeforeExpiration is chosen one would just encode an INTEGER with
>a
>>>context specific primitive tag of 0. But the tag associated with the
>>>outer element (warning) also needs to be included so the decoder can
>>>tell that a warning element was included (remember, it is optional).
>>>What is the right way to encode this?
>>>    
>>>
>>
>>If the tag default is IMPLICIT TAGS then the encoding is as
>>you've stated above. The implicit tagging suppresses the universal
>tag
>>of the INTEGER, but there is no universal tag (or length) for CHOICE
>>and implicit tagging never applies to a CHOICE.
>>
>>With IMPLICIT tags the warning element, when present, is encoded as
>>
>>    [constructed 0] length [primitive 0] length integer-value-octets
>>
>>With EXPLICIT tags the warning element, when present, is encoded as
>>
>>    [constructed 0] length [constructed 0] length
>>        [primitive UNIVERSAL 2] length integer-value-octets
>>
>>  
>>
>>>One ASN.1 compiler I used encoded the warning element as a
>constructed
>>>element that contains one integer (which allows two tags to
>>>be encoded,
>>>one associated with the constructed/container element and one with
>the
>>>integer itself). Is that the right thing to do?
>>>    
>>>
>>
>>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't
>say
>>whether EXPLICIT or IMPLICIT tagging should apply.
>>
>>Regards,
>>Steven
>>
>
>_______________________________________________
>Ldapext mailing list
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext
>_______________________________________________
>Ldapext mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: "Jim Sermersheim" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 28 Mar 2003 23:47:32 -0700
List-Id: LDAP Extension Working Group <ldapext.ietf.org>

I'd love to do this, but the fact is, values of controls and extended
operations are OCTET STRING types. It's entirely up to the control or
extended operation specification to define the format of the octets
(4.1.11 and 4.12). I believe it would be inappropriate to say anything
other than "if the control (or extended operation) specification defines
the format of the control value using ASN.1, it SHOULD also specify that
encoding be in accordance with the rules in 5.1". Even that, I feel is
stretching things a bit. Otherwise the protocol begins to take on
aspects of an extension guide.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 3/28/03 7:39:30 PM >>>
At 06:23 PM 3/28/2003, Jim Sermersheim wrote:
>I bet you're right.  (Now where is that LDAP extensions guidelines
>document...?)

I can add something to draft-zeilenga-ldap-ext about this...
but maybe it *might* be appropriate to cover this in the
revision of Section 5.1 of RFC 2251.  Loosely speaking,
values of controls and extended operations are elements
of LDAP and hence subject to Section 5.1 requirements.

I suggest someone suggest some text to LDAPBIS.

Alternatively (or maybe, additionally), this can be covered
in draft-zeilenga-ldap-ext.  I'd welcome text suggestions.

Kurt

>>>> Mark C Smith <[email-masked]> 3/28/03 7:32:16 AM >>>
>Thank you for your helpful response.
>
>One follow up question: in the absence of any indication, the default
>in 
>ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension 
>documents intend to use IMPLICIT (which for example is specified in 
>Appendix A of RFC 2251) but that fact may not be mentioned. One
>example:
>
>http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt

>
>
>-Mark
>
>
>Steven Legg wrote:
>
>>Mark,
>>
>>Mark C Smith wrote:
>>  
>>
>>>Someone asked me this week what the correct BER encoding is for a
>>>PasswordPolicyResponseValue (from
>>>
>>>    
>>>
>>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt

>
>>).
>>  
>>
>>>The ASN.1 from section 5.2 of the I-D is:
>>>
>>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>>       warning   [0] CHOICE OPTIONAL {
>>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>>>       error     [1] ENUMERATED OPTIONAL {
>>>           passwordExpired       (0),
>>>           accountLocked         (1),
>>>           changeAfterReset      (2),
>>>           passwordModNotAllowed (3),
>>>           mustSupplyOldPassword (4),
>>>           invalidPasswordSyntax (5),
>>>           passwordTooShort      (6),
>>>           passwordTooYoung      (7),
>>>           passwordInHistory     (8) } }
>>>    
>>>
>>
>>First up, there are syntax errors in this type definition.
>>It should read:
>>
>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>       warning   [0] CHOICE {
>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>OPTIONAL,
>>       error     [1] ENUMERATED {
>>           passwordExpired       (0),
>>           accountLocked         (1),
>>           changeAfterReset      (2),
>>           passwordModNotAllowed (3),
>>           mustSupplyOldPassword (4),
>>           invalidPasswordSyntax (5),
>>           passwordTooShort      (6),
>>           passwordTooYoung      (7),
>>           passwordInHistory     (8) } OPTIONAL }
>>
>>
>>  
>>
>>>Notice that the warning element is both OPTIONAL (with a context
>>>specific tag of 0) and a CHOICE with embedded context specific tags
>(0
>>>timeBeforeExpiration and 1 for graceLoginsRemaining).
>>>Normally, a CHOICE
>>>is encoded simply as whatever element as chosen, e.g., if
>>>timeBeforeExpiration is chosen one would just encode an INTEGER
with
>a
>>>context specific primitive tag of 0. But the tag associated with
the
>>>outer element (warning) also needs to be included so the decoder
can
>>>tell that a warning element was included (remember, it is
optional).
>>>What is the right way to encode this?
>>>    
>>>
>>
>>If the tag default is IMPLICIT TAGS then the encoding is as
>>you've stated above. The implicit tagging suppresses the universal
>tag
>>of the INTEGER, but there is no universal tag (or length) for CHOICE
>>and implicit tagging never applies to a CHOICE.
>>
>>With IMPLICIT tags the warning element, when present, is encoded as
>>
>>    [constructed 0] length [primitive 0] length integer-value-octets
>>
>>With EXPLICIT tags the warning element, when present, is encoded as
>>
>>    [constructed 0] length [constructed 0] length
>>        [primitive UNIVERSAL 2] length integer-value-octets
>>
>>  
>>
>>>One ASN.1 compiler I used encoded the warning element as a
>constructed
>>>element that contains one integer (which allows two tags to
>>>be encoded,
>>>one associated with the constructed/container element and one with
>the
>>>integer itself). Is that the right thing to do?
>>>    
>>>
>>
>>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't
>say
>>whether EXPLICIT or IMPLICIT tagging should apply.
>>
>>Regards,
>>Steven
>>
>
>_______________________________________________
>Ldapext mailing list
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext 
>_______________________________________________
>Ldapext mailing list
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

Subject: RE: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: "Ramsay, Ron" <[email-masked]>
To: "Jim Sermersheim" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 31 Mar 2003 14:14:04 +1000

I think all ASN.1 for a control should be in the form of an ASN.1 module instead of just snippets of ASN.1. RFC 2251 does just this in an appendix.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Saturday, 29 March 2003 17:48
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?

I'd love to do this, but the fact is, values of controls and extended
operations are OCTET STRING types. It's entirely up to the control or
extended operation specification to define the format of the octets
(4.1.11 and 4.12). I believe it would be inappropriate to say anything
other than "if the control (or extended operation) specification defines
the format of the control value using ASN.1, it SHOULD also specify that
encoding be in accordance with the rules in 5.1". Even that, I feel is
stretching things a bit. Otherwise the protocol begins to take on
aspects of an extension guide.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 3/28/03 7:39:30 PM >>>
At 06:23 PM 3/28/2003, Jim Sermersheim wrote:
>I bet you're right.  (Now where is that LDAP extensions guidelines
>document...?)

I can add something to draft-zeilenga-ldap-ext about this...
but maybe it *might* be appropriate to cover this in the
revision of Section 5.1 of RFC 2251.  Loosely speaking,
values of controls and extended operations are elements
of LDAP and hence subject to Section 5.1 requirements.

I suggest someone suggest some text to LDAPBIS.

Alternatively (or maybe, additionally), this can be covered
in draft-zeilenga-ldap-ext.  I'd welcome text suggestions.

Kurt

>>>> Mark C Smith <[email-masked]> 3/28/03 7:32:16 AM >>>
>Thank you for your helpful response.
>
>One follow up question: in the absence of any indication, the default
>in 
>ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension 
>documents intend to use IMPLICIT (which for example is specified in 
>Appendix A of RFC 2251) but that fact may not be mentioned. One
>example:
>
>http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt

>
>
>-Mark
>
>
>Steven Legg wrote:
>
>>Mark,
>>
>>Mark C Smith wrote:
>>  
>>
>>>Someone asked me this week what the correct BER encoding is for a
>>>PasswordPolicyResponseValue (from
>>>
>>>    
>>>
>>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt

>
>>).
>>  
>>
>>>The ASN.1 from section 5.2 of the I-D is:
>>>
>>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>>       warning   [0] CHOICE OPTIONAL {
>>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>>>       error     [1] ENUMERATED OPTIONAL {
>>>           passwordExpired       (0),
>>>           accountLocked         (1),
>>>           changeAfterReset      (2),
>>>           passwordModNotAllowed (3),
>>>           mustSupplyOldPassword (4),
>>>           invalidPasswordSyntax (5),
>>>           passwordTooShort      (6),
>>>           passwordTooYoung      (7),
>>>           passwordInHistory     (8) } }
>>>    
>>>
>>
>>First up, there are syntax errors in this type definition.
>>It should read:
>>
>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>       warning   [0] CHOICE {
>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>OPTIONAL,
>>       error     [1] ENUMERATED {
>>           passwordExpired       (0),
>>           accountLocked         (1),
>>           changeAfterReset      (2),
>>           passwordModNotAllowed (3),
>>           mustSupplyOldPassword (4),
>>           invalidPasswordSyntax (5),
>>           passwordTooShort      (6),
>>           passwordTooYoung      (7),
>>           passwordInHistory     (8) } OPTIONAL }
>>
>>
>>  
>>
>>>Notice that the warning element is both OPTIONAL (with a context
>>>specific tag of 0) and a CHOICE with embedded context specific tags
>(0
>>>timeBeforeExpiration and 1 for graceLoginsRemaining).
>>>Normally, a CHOICE
>>>is encoded simply as whatever element as chosen, e.g., if
>>>timeBeforeExpiration is chosen one would just encode an INTEGER
with
>a
>>>context specific primitive tag of 0. But the tag associated with
the
>>>outer element (warning) also needs to be included so the decoder
can
>>>tell that a warning element was included (remember, it is
optional).
>>>What is the right way to encode this?
>>>    
>>>
>>
>>If the tag default is IMPLICIT TAGS then the encoding is as
>>you've stated above. The implicit tagging suppresses the universal
>tag
>>of the INTEGER, but there is no universal tag (or length) for CHOICE
>>and implicit tagging never applies to a CHOICE.
>>
>>With IMPLICIT tags the warning element, when present, is encoded as
>>
>>    [constructed 0] length [primitive 0] length integer-value-octets
>>
>>With EXPLICIT tags the warning element, when present, is encoded as
>>
>>    [constructed 0] length [constructed 0] length
>>        [primitive UNIVERSAL 2] length integer-value-octets
>>
>>  
>>
>>>One ASN.1 compiler I used encoded the warning element as a
>constructed
>>>element that contains one integer (which allows two tags to
>>>be encoded,
>>>one associated with the constructed/container element and one with
>the
>>>integer itself). Is that the right thing to do?
>>>    
>>>
>>
>>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't
>say
>>whether EXPLICIT or IMPLICIT tagging should apply.
>>
>>Regards,
>>Steven
>>
>
>_______________________________________________
>Ldapext mailing list
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext 
>_______________________________________________
>Ldapext mailing list
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

Subject: RE: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: "Jim Sermersheim" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sun, 30 Mar 2003 22:11:20 -0700
List-Id: LDAP Extension Working Group <ldapext.ietf.org>

I agree, but I also note that there's not even a requirement for control
values to be described using ASN.1.

>>> "Ramsay, Ron" <[email-masked]> 3/30/03 9:14:04 PM >>>
I think all ASN.1 for a control should be in the form of an ASN.1
module instead of just snippets of ASN.1. RFC 2251 does just this in an
appendix.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Saturday, 29 March 2003 17:48
To: [email-masked] 
Cc: [email-masked]; [email-masked]; [email-masked] 
Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?

I'd love to do this, but the fact is, values of controls and extended
operations are OCTET STRING types. It's entirely up to the control or
extended operation specification to define the format of the octets
(4.1.11 and 4.12). I believe it would be inappropriate to say anything
other than "if the control (or extended operation) specification
defines
the format of the control value using ASN.1, it SHOULD also specify
that
encoding be in accordance with the rules in 5.1". Even that, I feel is
stretching things a bit. Otherwise the protocol begins to take on
aspects of an extension guide.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 3/28/03 7:39:30 PM >>>
At 06:23 PM 3/28/2003, Jim Sermersheim wrote:
>I bet you're right.  (Now where is that LDAP extensions guidelines
>document...?)

I can add something to draft-zeilenga-ldap-ext about this...
but maybe it *might* be appropriate to cover this in the
revision of Section 5.1 of RFC 2251.  Loosely speaking,
values of controls and extended operations are elements
of LDAP and hence subject to Section 5.1 requirements.

I suggest someone suggest some text to LDAPBIS.

Alternatively (or maybe, additionally), this can be covered
in draft-zeilenga-ldap-ext.  I'd welcome text suggestions.

Kurt

>>>> Mark C Smith <[email-masked]> 3/28/03 7:32:16 AM >>>
>Thank you for your helpful response.
>
>One follow up question: in the absence of any indication, the default
>in 
>ASN.1 is EXPLICIT tagging, right? I suspect many LDAP extension 
>documents intend to use IMPLICIT (which for example is specified in 
>Appendix A of RFC 2251) but that fact may not be mentioned. One
>example:
>
>http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt

>
>
>-Mark
>
>
>Steven Legg wrote:
>
>>Mark,
>>
>>Mark C Smith wrote:
>>  
>>
>>>Someone asked me this week what the correct BER encoding is for a
>>>PasswordPolicyResponseValue (from
>>>
>>>    
>>>
>>http://www.ietf.org/internet-drafts/draft-behera-ldap-password-policy-06.txt

>
>>).
>>  
>>
>>>The ASN.1 from section 5.2 of the I-D is:
>>>
>>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>>       warning   [0] CHOICE OPTIONAL {
>>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>>>       error     [1] ENUMERATED OPTIONAL {
>>>           passwordExpired       (0),
>>>           accountLocked         (1),
>>>           changeAfterReset      (2),
>>>           passwordModNotAllowed (3),
>>>           mustSupplyOldPassword (4),
>>>           invalidPasswordSyntax (5),
>>>           passwordTooShort      (6),
>>>           passwordTooYoung      (7),
>>>           passwordInHistory     (8) } }
>>>    
>>>
>>
>>First up, there are syntax errors in this type definition.
>>It should read:
>>
>>    PasswordPolicyResponseValue ::= SEQUENCE {
>>       warning   [0] CHOICE {
>>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
>>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
>OPTIONAL,
>>       error     [1] ENUMERATED {
>>           passwordExpired       (0),
>>           accountLocked         (1),
>>           changeAfterReset      (2),
>>           passwordModNotAllowed (3),
>>           mustSupplyOldPassword (4),
>>           invalidPasswordSyntax (5),
>>           passwordTooShort      (6),
>>           passwordTooYoung      (7),
>>           passwordInHistory     (8) } OPTIONAL }
>>
>>
>>  
>>
>>>Notice that the warning element is both OPTIONAL (with a context
>>>specific tag of 0) and a CHOICE with embedded context specific tags
>(0
>>>timeBeforeExpiration and 1 for graceLoginsRemaining).
>>>Normally, a CHOICE
>>>is encoded simply as whatever element as chosen, e.g., if
>>>timeBeforeExpiration is chosen one would just encode an INTEGER
with
>a
>>>context specific primitive tag of 0. But the tag associated with
the
>>>outer element (warning) also needs to be included so the decoder
can
>>>tell that a warning element was included (remember, it is
optional).
>>>What is the right way to encode this?
>>>    
>>>
>>
>>If the tag default is IMPLICIT TAGS then the encoding is as
>>you've stated above. The implicit tagging suppresses the universal
>tag
>>of the INTEGER, but there is no universal tag (or length) for CHOICE
>>and implicit tagging never applies to a CHOICE.
>>
>>With IMPLICIT tags the warning element, when present, is encoded as
>>
>>    [constructed 0] length [primitive 0] length integer-value-octets
>>
>>With EXPLICIT tags the warning element, when present, is encoded as
>>
>>    [constructed 0] length [constructed 0] length
>>        [primitive UNIVERSAL 2] length integer-value-octets
>>
>>  
>>
>>>One ASN.1 compiler I used encoded the warning element as a
>constructed
>>>element that contains one integer (which allows two tags to
>>>be encoded,
>>>one associated with the constructed/container element and one with
>the
>>>integer itself). Is that the right thing to do?
>>>    
>>>
>>
>>Yes, if the tag default is IMPLICIT TAGS, though the draft doesn't
>say
>>whether EXPLICIT or IMPLICIT tagging should apply.
>>
>>Regards,
>>Steven
>>
>
>_______________________________________________
>Ldapext mailing list
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext 
>_______________________________________________
>Ldapext mailing list
>[email-masked] 
>https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

Subject: RE: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: "Steven Legg" <[email-masked]>
To: "'Mark C Smith'" <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 31 Mar 2003 15:20:38 +1000
List-Id: LDAP Extension Working Group <ldapext.ietf.org>

Mark,

Mark C Smith wrote:
> One follow up question: in the absence of any indication, the 
> default in 
> ASN.1 is EXPLICIT tagging, right?

The default for a module definition with an empty TagDefault is
EXPLICIT tagging, but for a fragment of ASN.1 that is not wrapped
in a module definition no particular kind of tagging can be assumed.
The ASN.1 standards don't recognize a standalone type definition
as valid use of the notation.

The tagging issue needs to be addressed by either providing a
module definition, perhaps as a normative annex, or by an explicit
statement in the specification.

In theory we should also be saying something about the extensibility
of any standalone ASN.1 type definition, but this only becomes a critical
concern if PER is being used. X.500 has long had a presumption of
extensibility.

Regards,
Steven 

> I suspect many LDAP extension 
> documents intend to use IMPLICIT (which for example is specified in 
> Appendix A of RFC 2251) but that fact may not be mentioned. 
> One example:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-
> vlv-09.txt
> 
> -Mark
> 
> 
> Steven Legg wrote:
> 
> >Mark,
> >
> >Mark C Smith wrote:
> >  
> >
> >>Someone asked me this week what the correct BER encoding is for a
> >>PasswordPolicyResponseValue (from
> >>
> >>    
> >>
> >http://www.ietf.org/internet-drafts/draft-behera-ldap-passwor
> d-policy-06.txt
> >).
> >  
> >
> >>The ASN.1 from section 5.2 of the I-D is:
> >>
> >>    PasswordPolicyResponseValue ::= SEQUENCE {
> >>       warning   [0] CHOICE OPTIONAL {
> >>           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
> >>           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) }
> >>       error     [1] ENUMERATED OPTIONAL {
> >>           passwordExpired       (0),
> >>           accountLocked         (1),
> >>           changeAfterReset      (2),
> >>           passwordModNotAllowed (3),
> >>           mustSupplyOldPassword (4),
> >>           invalidPasswordSyntax (5),
> >>           passwordTooShort      (6),
> >>           passwordTooYoung      (7),
> >>           passwordInHistory     (8) } }
> >>    
> >>
> >
> >First up, there are syntax errors in this type definition.
> >It should read:
> >
> >    PasswordPolicyResponseValue ::= SEQUENCE {
> >       warning   [0] CHOICE {
> >           timeBeforeExpiration  [0] INTEGER (0 .. maxInt),
> >           graceLoginsRemaining  [1] INTEGER (0 .. maxInt) } 
> OPTIONAL,
> >       error     [1] ENUMERATED {
> >           passwordExpired       (0),
> >           accountLocked         (1),
> >           changeAfterReset      (2),
> >           passwordModNotAllowed (3),
> >           mustSupplyOldPassword (4),
> >           invalidPasswordSyntax (5),
> >           passwordTooShort      (6),
> >           passwordTooYoung      (7),
> >           passwordInHistory     (8) } OPTIONAL }
> >
> >
> >  
> >
> >>Notice that the warning element is both OPTIONAL (with a context
> >>specific tag of 0) and a CHOICE with embedded context 
> specific tags (0
> >>timeBeforeExpiration and 1 for graceLoginsRemaining).
> >>Normally, a CHOICE
> >>is encoded simply as whatever element as chosen, e.g., if
> >>timeBeforeExpiration is chosen one would just encode an 
> INTEGER with a
> >>context specific primitive tag of 0. But the tag associated with the
> >>outer element (warning) also needs to be included so the decoder can
> >>tell that a warning element was included (remember, it is optional).
> >>What is the right way to encode this?
> >>    
> >>
> >
> >If the tag default is IMPLICIT TAGS then the encoding is as
> >you've stated above. The implicit tagging suppresses the 
> universal tag
> >of the INTEGER, but there is no universal tag (or length) for CHOICE
> >and implicit tagging never applies to a CHOICE.
> >
> >With IMPLICIT tags the warning element, when present, is encoded as
> >
> >    [constructed 0] length [primitive 0] length integer-value-octets
> >
> >With EXPLICIT tags the warning element, when present, is encoded as
> >
> >    [constructed 0] length [constructed 0] length
> >        [primitive UNIVERSAL 2] length integer-value-octets
> >
> >  
> >
> >>One ASN.1 compiler I used encoded the warning element as a 
> constructed
> >>element that contains one integer (which allows two tags to
> >>be encoded,
> >>one associated with the constructed/container element and 
> one with the
> >>integer itself). Is that the right thing to do?
> >>    
> >>
> >
> >Yes, if the tag default is IMPLICIT TAGS, though the draft 
> doesn't say
> >whether EXPLICIT or IMPLICIT tagging should apply.
> >
> >Regards,
> >Steven
> >
> 
> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ldapext
> 
_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: [email-masked] (Mark C Smith)
To: Jim Sermersheim <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 31 Mar 2003 10:28:41 -0500

Jim Sermersheim wrote:

>I'd love to do this, but the fact is, values of controls and extended
>operations are OCTET STRING types. It's entirely up to the control or
>extended operation specification to define the format of the octets
>(4.1.11 and 4.12). I believe it would be inappropriate to say anything
>other than "if the control (or extended operation) specification defines
>the format of the control value using ASN.1, it SHOULD also specify that
>encoding be in accordance with the rules in 5.1". Even that, I feel is
>stretching things a bit. Otherwise the protocol begins to take on
>aspects of an extension guide.
>
I think a statement like you suggest that references section 5.1 would 
be a reasonable thing to add to the protocol document. I think it will 
do more harm than good to allow control authors to use different 
encoding approaches (but if someone can come up with a real world 
example where following 5.1 is unacceptable in a control, I will change 
my mind). I think current practice is to follow 5.1, but we just don't 
have that requirement written down anywhere.

-Mark

Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: "Kurt D. Zeilenga" <[email-masked]>
To: "Jim Sermersheim" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 31 Mar 2003 07:45:56 -0800

At 10:47 PM 3/28/2003, Jim Sermersheim wrote:
>I'd love to do this, but the fact is, values of controls and extended
>operations are OCTET STRING types.

Yes, but as LDAP extensions are defining "LDAP protocol elements",
I think it is reasonable to say that this SHALL apply to control and
extended operation values which are described in term of ASN.1 and
encoded using BER (as described in 5.1) unless the technical
specification defining the LDAP protocol element explicitly states
otherwise.

I encourage extension authors to include to define the
term BER-encoded as follows.
   Protocol elements are described using ASN.1 [X.680].  The term
   "BER-encoded" means the element is to be encoded using the Basic
   Encoding Rules [X.690] under the restrictions detailed in
   Section 5.1 of [RFC2251].

Kurt 

Subject: Re: [ldapext] BER encoding of PasswordPolicyResponseValue?
From: "Kurt D. Zeilenga" <[email-masked]>
To: "Jim Sermersheim" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 31 Mar 2003 07:45:56 -0800
List-Id: LDAP Extension Working Group <ldapext.ietf.org>

At 10:47 PM 3/28/2003, Jim Sermersheim wrote:
>I'd love to do this, but the fact is, values of controls and extended
>operations are OCTET STRING types.

Yes, but as LDAP extensions are defining "LDAP protocol elements",
I think it is reasonable to say that this SHALL apply to control and
extended operation values which are described in term of ASN.1 and
encoded using BER (as described in 5.1) unless the technical
specification defining the LDAP protocol element explicitly states
otherwise.

I encourage extension authors to include to define the
term BER-encoded as follows.
   Protocol elements are described using ASN.1 [X.680].  The term
   "BER-encoded" means the element is to be encoded using the Basic
   Encoding Rules [X.690] under the restrictions detailed in
   Section 5.1 of [RFC2251].

Kurt 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext