I think you're reading the section differently from me. My reading is that the Normalized Request String is composed of each of the itemized elements, with newlines appended to them, concatenated together.
"ITEM_1\nITEM_2\n[...]ITEM_8\nITEM_9\n" My reading is that none of the items - per se - end with a \n. From the list, item 1 is "The access token", not "The access token followed by a newline." So, by analogy, I read Section 3.3.1.1 as telling me how to construct the string ITEM_9 - not telling me how to construct the string "ITEM_9\n". I think you're reading the spec as saying that the NormalizedRequestString is "ITEM_1ITEM_2[...]ITEM_8ITEM_9 so that the trailing '\n's are part of the ITEMs. But I can't square that with the description of the items in the list using the text currently there. For what it's worth, I'm not being pernickety for no reason - I came across this because I wrote a bunch of tests for my parameter-normalization function, based on reading the description of the algorithm, and then found this issue only because pasting the example from the spec into my testsuite caused it to fail, due to the extra trailing newline. Toby On Sun, Feb 13, 2011 at 12:10 PM, Skylar Woodward <sky...@kiva.org> wrote: > I think it's meant to be there. If you look at Signature Base String > construction, item 9 is a normal "line item" just like all others and should > have a newline at the end. So you can think of it as the params as one sting > w/ newline between followed by a newline. In the example, it looks like each > param is followed by a newline which is not exactly how the spec words it, > but it's the same result. > > For me, ending the params with a newline results in the same signature values > as the spec. > > What might be unclear is if there should be an empty newline if the query > string is empty. Eran? > > > On Feb 13, 2011, at 2:57 AM, Toby White wrote: > >> * I think there's an error in the parameters normalization example. >> >> The final output of the normalization algorithm at the end of 3.3.1.1 >> is given as: >> >> a2=r%20b\n >> a3=2%20q\n >> a3=a\n >> b5=%3D%253D\n >> c%40=\n >> c2=\n >> >> but I don't think the final newline should be there. By my reading of >> the description of the algorithm, there's no reason for the final >> newline to be appended - and if it should be appended, then the >> Normalized Request String example at the end of 3.3.1 ought to end >> with *two* newlines, since each of the HTTP request elements should be >> followed by a newline character. > > -- http://timetric.com 2nd Floor, White Bear Yard, 144a Clerkenwell Road, London EC1R 5DF phone: +44 20 3286 0677 (office), +44 7747 603618 (mobile) twitter: @timetric, @tow21 | skype: tobyohwhite _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
