Re: [woes] New WOES charter proposal

<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: woes-bounces@ietf.org [mailto:woes-bounces@ietf.org] On Behalf Of Stephen Farrell
> Sent: Friday, July 15, 2011 5:36 PM
> To: Dave CROCKER
> Cc: woes@ietf.org
> 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
> woes@ietf.org
> https://www.ietf.org/mailman/listinfo/woes
> 
> _______________________________________________
> woes mailing list
> woes@ietf.org
> https://www.ietf.org/mailman/listinfo/woes