On Mar 10, 2010, at 3:47 PM, Paul Lindner wrote: > Standards have size limits to overcome operational issues all the time.
Standards usually standardize on the things necessary for interoperability, and token size isn't a necessity for interoperability unless we make it one. No-one has explained the benefit of doing that yet. > For an extreme example look at the backflips that MIME goes through to > insure that mail can be delivered by even the most hostile relay. (Including > systems using EBCDIC, and systems that mangle payloads!) > > If there are no bounds on the size of a token the end result is that some > parts of the protocol move from MAY to MUST. For example, many > firewall/proxy services in the wild will truncate URLs and even HTTP headers > much shorter than the 4k normally assumed. Ergo, POST support is now a > MUST. And in environments without such intermediaries, tokens of much larger sizes may be sent without problems. I agree that implementation considerations such as URL length and so on may be relevant in some environments, but I would oppose some mandatory limit in OAuth on token size. It's fine, however, to say that if we rely on HTTP as a substrate that we should be governed by any relevant and documented standard HTTP (or other relevant specifications) limits, and provide implementation advice to suggest that in some environments where implementations don't follow the standards, URLs may be truncated by *some implementations* (for example). Regards, - johnk > > On Mar 10, 2010, at 8:30 AM, John Kemp wrote: > >> On Mar 10, 2010, at 11:16 AM, Moritz Maisel wrote: >> >>> On 03/10/2010 04:42 PM, John Kemp wrote: >>>> One reason I can imagine is to make it possible to encode information into >>>> the token itself so that the token can be "self-contained" (mentioned also >>>> by others on this list). >>>> >>> >>> Though thats an interesting option, compatibility of implementations >>> might be easier to achieve by strict specifications like "maximum of 256 >>> characters". >> >> Could you explain why you need to standardize a maximum token length, or why >> you would want to standardize on implementations of a token store rather >> than a token-exchange protocol here? >> >>> >>> Just to get an idea about the situation: Is the mentioned >>> "self-contained token" a common scenario / popular demand that needs to >>> be covered? >> >> Yes it is. Several people on this list have already mentioned it. >> >> Regards, >> >> - johnk >> >>> >>> Regards, >>> Moritz >>> >>> -- >>> sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf >>> HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois >>> Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 >>> >>> www.sipgate.de - www.sipgate.at - www.sipgate.co.uk >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
