<hat type="individual"/> It's not clear to me what practical difference this requirement makes. I would expect that the DER encoding of CMS is probably more compact than a comparable JSON format, so you're not optimizing length by using JSON. And JSON doesn't define a URL-safe encoding. If minimizing the size of something in a URL is really your goal, it seems likely that size(base64(cms)) < size(urlencode(json)).
Or, if you're willing to take the JSON penalty in byte-efficiency, are you trying to argue that there are fields that should be left out relative to CMS? Could you point to some examples? --Richard On Jul 15, 2011, at 9:13 PM, Mike Jones wrote: > Some use cases require a compact, URL-safe data representation. For > instance, this is needed when the data is passed in a URL query parameter - > particularly for feature phone browsers that may limit URLs to 1024 or > sometimes even 256 characters. That's one concrete example of something not > covered by CMS. > > Some end-to-end use cases require a JSON key representation and ways of > referring to them. That's another concrete example of something not covered > in CMS. > > -- Mike > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Stephen Farrell > Sent: Friday, July 15, 2011 5:36 PM > To: Dave CROCKER > Cc: [email protected] > Subject: Re: [woes] New WOES charter proposal > > > > On 16/07/11 01:23, Dave CROCKER wrote: >> >> On 7/14/2011 1:45 PM, Stephen Farrell wrote: >>>> The first requirement is for proponents to provide much more >>>> explicit details about what is being proposed in the use of CMS. >> ... >>> Well, I don't really follow your logic there, but we're not aiming to >>> do a new thing here. >> ... >>> Anyway the path for developing yet another crypto format is a pretty >>> well trodden one and IMO CMS is the best current starting point for >>> that process, so I think its entirely reasonable to ask people why >>> they disagree with that. >>> >>> It does of course presume familiarity with CMS, but then that should >>> be a prerequisite for working on woes, really. >> >> >> Steve, >> >> Oh. This working group is merely a CMS encoding exercise? That was >> not at all clear previously. >> >> I suspect I am not the only one who missed this as the anchoring and >> inflexible premise to the work. (For reference, that requires even >> stronger language than is in the current draft.) > > Maybe you could put [] around the sarcasm, given that this is JSON related? > :-) > > I asked for examples of what's not covered by CMS but is needed here. I did > that actually wanting to get an answer since I may well be missing something. > (So far, no substantive answer has been offered.) I was not trying to score > some rhetorical points. > > S. > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes > > _______________________________________________ > woes mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/woes _______________________________________________ woes mailing list [email protected] https://www.ietf.org/mailman/listinfo/woes
