Recordon, David
> Sent: Wednesday, September 27, 2006 1:13 PM
> To: Josh Hoyt; Marius Scurtescu; Brad Fitzpatrick
> Cc: specs@openid.net
> Subject: RE: Request for comments: Sorting fields in
> signature generation-Call for votes
>
> I don't think multiple paramet
On 28-Sep-06, at 3:18 AM, Martin Atkins wrote:
> Josh Hoyt wrote:
>>
>>> If that weren't so, then why is there the "openid." prefix to the
>>> parameters in some of the messages?
>>
>> The reason that the parameters have "openid." at the beginning is so
>> that it is clear that they are part of t
> Can we get +1/-1 on multiple parameters with the same name
> from people without @sxip.com or @janrain.com e-mail addresses?
Vote is too unclear -- it needs to contain an action.
Anyway, -1 on "allow multiple parameters with the same name."
Hans
___
Josh Hoyt wrote:
>
>> If that weren't so, then why is there the "openid." prefix to the
>> parameters in some of the messages?
>
> The reason that the parameters have "openid." at the beginning is so
> that it is clear that they are part of the OpenID protocol message and
> not intended to be ope
On 9/27/06, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> > Huh? I don't see anything in that section about a requirement to echo
> > back parameters.
>
> Not a requirement, but I read the second paragraph as implying they
> can/could be used.
An IdP is not forbidden from echoing back any unknown param
On 27-Sep-06, at 10:39 AM, Josh Hoyt wrote:
> On 9/27/06, Johnny Bufu <[EMAIL PROTECTED]> wrote:
>> Section 5.2 of draft 9 seems to imply, at least, that pass-through
>> parameters are allowed, and specifies how the parties involved in the
>> transaction should handle the openid / non-openid param
27, 2006 12:20 PM
To: Marius Scurtescu
Cc: specs@openid.net
Subject: Re: Request for comments: Sorting fields in signature
generation -Call for votes
On 9/27/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> please keep in mind that we are not asking for some fancy new
> technology or
-1 on multiple parameters with the same name.
=Drummond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Josh Hoyt
Sent: Wednesday, September 27, 2006 12:20 PM
To: Marius Scurtescu
Cc: specs@openid.net
Subject: Re: Request for comments: Sorting fields in
On 27-Sep-06, at 12:22 PM, Johannes Ernst wrote:
> On Sep 27, 2006, at 12:08, Marius Scurtescu wrote:
>
>> Multi-valued fields represent lists. Lists are very useful data
>> structures, and yes, lists can be misused/abused.
>
> Now you are knocking down the wrong strawman. Just because there
>
On 27-Sep-06, at 12:20 PM, Josh Hoyt wrote:
> On 9/27/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> please keep in mind that we are not asking for some fancy new
>> technology or feature, just conformance with a very basic an wide
>> spread convention of handling parameters in HTTP/HTML.
Th
On 27-Sep-06, at 12:18 PM, Josh Hoyt wrote:
> On 9/27/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> It is quite common (and natural) to use multi-valued fields for check
>> boxes and multi select list boxes.
>
> But browsers (the things that do HTML form submission) will not be
> generating O
On Sep 27, 2006, at 12:08, Marius Scurtescu wrote:
On 27-Sep-06, at 11:10 AM, Johannes Ernst wrote:
On Sep 27, 2006, at 9:48, Granqvist, Hans wrote:
Johannes, just to clarify, are you against allowing
multiple same-name params?
I don't like multi-valued fields, because in my experience, i
On 9/27/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> please keep in mind that we are not asking for some fancy new
> technology or feature, just conformance with a very basic an wide
> spread convention of handling parameters in HTTP/HTML.
As Kevin pointed out, we are not working on the HTTP/
On 9/27/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> It is quite common (and natural) to use multi-valued fields for check
> boxes and multi select list boxes.
But browsers (the things that do HTML form submission) will not be
generating OpenID messages. OpenID libraries will be doing that. S
On 27-Sep-06, at 11:10 AM, Johannes Ernst wrote:
> On Sep 27, 2006, at 9:48, Granqvist, Hans wrote:
>
>> Johannes, just to clarify, are you against allowing
>> multiple same-name params?
>
> I don't like multi-valued fields, because in my experience, it is a
> slippery slope that usually leads s
On 27-Sep-06, at 10:09 AM, Josh Hoyt wrote:
> On 9/27/06, Barry Ferg <[EMAIL PROTECTED]> wrote:
>> For that matter, isn't having implementation issues in certain
>> restrictive development environments drive the specification kind of
>> like the tail wagging the dog?
>
> I am attempting to be prag
On Sep 27, 2006, at 9:55, Barry Ferg wrote:
Johannes, if as you say "many people do this kind of thing in many
circumstances", why limit their ability to do so in this circumstance?
I'm simply acknowledging that many people do this.
Of course, a substantially larger number of people doesn't
On Sep 27, 2006, at 9:48, Granqvist, Hans wrote:
Johannes, just to clarify, are you against allowing
multiple same-name params?
I don't like multi-valued fields, because in my experience, it is a
slippery slope that usually leads somewhere one does not want to end
up. It tends to go like
On 9/27/06, Barry Ferg <[EMAIL PROTECTED]> wrote:
> This proposal doesn't _force_ anyone to us multiple
> parameters with the same name. I'm in favour of keeping the
> specification flexible by not imposing unnecessary restrictions on
> future extensions to the protocol.
Why require the integers i
On 9/27/06, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> Section 5.2 of draft 9 seems to imply, at least, that pass-through
> parameters are allowed, and specifies how the parties involved in the
> transaction should handle the openid / non-openid parameters.
Huh? I don't see anything in that section
On 26-Sep-06, at 4:48 PM, Josh Hoyt wrote:
> No one has written a proposal for pass-through arguments and it's not
> in any specification, so it's hard to answer your objection. If
> someone were to propose adding pass-through parameters to the
> specification, I would argue that:
Section 5.2 of
On 9/27/06, Barry Ferg <[EMAIL PROTECTED]> wrote:
> For that matter, isn't having implementation issues in certain
> restrictive development environments drive the specification kind of
> like the tail wagging the dog?
I am attempting to be pragmatic. Why add something to the
specification that ma
On 9/27/06, David Fuelling <[EMAIL PROTECTED]> wrote:
> Just for clarification -- if duplicate parameters of the same name are NOT
> allowed by the spec, would one still be able to encode multiple values in
> the same key/value pair? Wouldn't this accomplish the same result as
> allowing duplicate
Johannes, if as you say "many people do this kind of thing in many
circumstances", why limit their ability to do so in this
circumstance? This proposal doesn't _force_ anyone to us multiple
parameters with the same name. I'm in favour of keeping the
specification flexible by not imposing
> > I think the real topic of this discussion is whether or not
> multiple
> > parameters with the same name should be allowed by the
> specification.
>
> I'd support the motion of not doing that.
>
Johannes, just to clarify, are you against allowing
multiple same-name params?
Hans
Yes, you can work around the limitation. But why introduce a
limitation for something widely used and then work around it?
Marius
On 27-Sep-06, at 7:43 AM, David Fuelling wrote:
> Just for clarification -- if duplicate parameters of the same name
> are NOT
> allowed by the spec, would one st
Just for clarification -- if duplicate parameters of the same name are NOT
allowed by the spec, would one still be able to encode multiple values in
the same key/value pair? Wouldn't this accomplish the same result as
allowing duplicate key names?
Not sure if this would be a bad idea, or not, but
On 26-Sep-06, at 4:53 PM, Josh Hoyt wrote:
> On 9/26/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
>> You can use either HTTP_RAW_POST_DATA or reading from
>> php://input, this gives you the url encoded list of parameters.
>> Parsing this is trivial.
>>
>> I would guess that there is a work arou
On 9/26/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> You can use either HTTP_RAW_POST_DATA or reading from
> php://input, this gives you the url encoded list of parameters.
> Parsing this is trivial.
>
> I would guess that there is a work around for Ruby on Rails as well.
But why make people
On 26-Sep-06, at 4:13 PM, Josh Hoyt wrote:
> On 9/26/06, Barry Ferg <[EMAIL PROTECTED]> wrote:
>> The signature generation algorithm specifies that the fields to be
>> signed be ordered in byte order form. It seems to be implied that
>> the ordering is based on using the field names as sorting ke
On 9/26/06, Marius Scurtescu <[EMAIL PROTECTED]> wrote:
> > Pass-through parameters are *not part of any OpenID specification.*
>
> They are not, but in order to be able to pass them through you have
> to be able to deal with them. Also, you may have to sign them as well.
No one has written a prop
On Sep 26, 2006, at 16:13, Josh Hoyt wrote:
I think the real topic of this discussion is whether or not multiple
parameters with the same name should be allowed by the specification.
I'd support the motion of not doing that.
I realize many people do this kind of thing in many circumstances,
On 26-Sep-06, at 4:13 PM, Josh Hoyt wrote:
>> Pass-through (or "echo") parameters and potentially some OpenID
>> extension parameters may include fields with multiple values in order
>> to communicate arrays of data, etc.
>
> Attribute exchange and other extensions can *easily* be designed not
> t
Request for comments: Sorting fields in
> signature generation
>
> On 9/26/06, Granqvist, Hans <[EMAIL PROTECTED]> wrote:
> > Does this problem exist if SIGNALL goes away?
>
> If there are multiple parameters with the same name, the
> problem is there
On 9/26/06, Granqvist, Hans <[EMAIL PROTECTED]> wrote:
> Does this problem exist if SIGNALL goes away?
If there are multiple parameters with the same name, the problem is
there, with or without SIGNALL, unfortunately.
Josh
___
specs mailing list
specs@o
On 9/26/06, Barry Ferg <[EMAIL PROTECTED]> wrote:
> The signature generation algorithm specifies that the fields to be
> signed be ordered in byte order form. It seems to be implied that
> the ordering is based on using the field names as sorting keys
I think the real topic of this discussion is
Does this problem exist if SIGNALL goes away?
Hans
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Barry Ferg
> Sent: Tuesday, September 26, 2006 3:52 PM
> To: specs@openid.net
> Subject: Request for comments: Sorting fields in signature genera
37 matches
Mail list logo
