Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt

[Kathleen Moriarty <[e-mail]>]

Hi Stephen,

On Tue, Dec 30, 2014 at 2:48 PM, Barry Leiba <[e-mail]> wrote:
> On just a couple of points...
>
>>> Page 6/7/13, Figure 1/2/3: I'm not sure that something that is
>>> entirely textural is best called a "Figure". But in any case, since
>>> the text is, or at least has, lines that are flush left, it looks like
>>> part of the preceding text and there isn't a clear demarcation of the
>>> start. I recommend that the body of the Figures be indented 3 or 4
>>> spaces.
>>
>> I'd prefer let the RFC editor fix those if needed.
>
> I think that if we think a change in the formatting would make things
> clearer, we should do that ourselves, and not defer it to the RFC
> Editor.  *We* should be happy with the document before we send it
> over.

I agree with Barry here, especially since you are providing an -09 soon.

>
>>> Page 19, IANA Considerations: It seems from
>>> draft-leiba-coton-iana-5226bis that IANA would prefer IANA
>>> Considerations to be written in the past tense as if the actions had
>>> already been accomplished, presumably to minimize IANA re-writing
>>> effort. Thus, I suggest that consideration be given to changing the
>>> initial part, between the Section 9 heading and the Section 9.1
>>> heading, to the following and making similar changes in the remainder
>>> of the IANA Considerations Section:
>
> I'm with Stephen here: please leave this alone.  At this point, the
> document is making a request, and that's a fine way to put it.

I'm fine with leaving this as well.
>
>>> Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted
>>> UTF8 string". There should probably be a Reference column. "a small
>>> positive integer" is undefined.
>>
>> Oh come on. Small positive integer utterly clear as is unformatted
>> string in this context. UTF8 isn't needed here as this is not meant
>> to be seen by a user.
>
> With this and all other strings, the question isn't whether users are
> going to see it or not, but how implementors are supposed to know what
> a "string" is and how to create it.  If it's an arbitrary sequence of
> bytes, then it should say that, rather than "string".  If it's really
> a string and is meant to represent characters in some encoding system,
> then it needs to say either what encoding system that is (UTF-8,
> US-ASCII, or whatever) or that it doesn't matter and that any encoding
> can be used.  The latter only works if the string is never consumed by
> an entity other than the one that created it.

Thanks Donald & Barry.

Best regards,
Kathleen

>
> Barry
>



-- 

Best regards,
Kathleen