Thanks a lot. I finally make 3 s/not/NOT/ and 2 s/MAY/may/.
@@ -410,7 +410,7 @@
of sequence.
Anonymous Authentication: The establishment of the security
- context SHOULD not reveal the initiator's identity to the context
+ context SHOULD NOT reveal the initiator's identity to the context
acceptor.
Some mechanisms may not support all OPTIONAL services, and some
@@ -2665,7 +2665,7 @@
ability may depend on the availability of system resources at the
time that wrap is called. However, if the implementation itself
imposes an upper limit on the length of messages that may be
- processed by wrap, the implementation SHOULD not return a value that
+ processed by wrap, the implementation SHOULD NOT return a value that
is greater than this length.
Parameters:
@@ -2855,7 +2855,7 @@
The implementation MAY constrain the set of processes by which the
inter-process token may be imported, either as a function of local
security policy, or as a result of implementation decisions. For
- example, some implementations MAY constrain contexts to be passed
+ example, some implementations may constrain contexts to be passed
only between processes that run under the same account, or which are
part of the same process group.
@@ -3046,7 +3046,7 @@
public boolean isProtReady()
Returns "true" if the per-message operations can be applied over the
- context. Some mechanisms MAY allow the usage of per-message
+ context. Some mechanisms may allow the usage of per-message
operations before the context is fully established. This will also
indicate that the get methods will return actual context state
characteristics instead of the desired ones.
@@ -3713,7 +3713,7 @@
outputToken The output token that SHOULD be sent to the peer.
Can be null if no such token is available. It
- MUST not be an empty array. When provided, the
+ MUST NOT be an empty array. When provided, the
array will be cloned to protect against
subsequent modifications.
Thanks
Weijun
> On Feb 8, 2018, at 6:57 AM, Benjamin Kaduk <[email protected]> wrote:
>
> On Wed, Feb 07, 2018 at 05:43:58PM -0500, Greg Hudson wrote:
>> On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should
> [line 2519]
>> --> SHOULD, since elsewhere we use SHOULD
>>> for sending the error token to the peer.
>>
>> No opinion. You could make a case for "that should be sent" being
>> either descriptive on the token or prescriptive on the application.
>
> Re-reading, I agree with you and retract the suggestion.
>
>>> Line 2561, I could go either way on "may" vs. "MAY" -- the argument
>>> for the former would be that it's just stating an attribute of the
>>> operation, and this text is describing something specified elsewhere
>>> and not introducing any restrictions or giving guidance on it.
>>> Similarly for acceptSecContext on line 2597.
>>
>> I think that's a MAY. It seems prescriptive on the method implementation.
>
> Okay.
>
>>> Line 2668, SHOULD not --> SHOULD NOT
>>
>> Agree.
>>
>>> Line 2858, MAY --> may, since this is just describing what some
>>> implementations could be doing and not exactly granting permission
>>> for it.
>>
>> Sure, and it's an example.
>>
>>> I guess for consistency I should say the same thing about line 3049.
>>
>> I guess "may" here, but no strong opinion.
>>
>>> Line 3716, MUST not --> MUST NOT
>>
>> Agree.
>
> Thanks for double-checking my work.
>
> -Ben
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
