Re: [woes] New WOES charter proposal

I now find myself hoping this is not the beginning someone making a case
for ASN.1 encoding in WOES.

For my edification, can someone comment on how CMS would likely be
referenced in WOES? Would it likely be a normative reference (i.e. key
transport/wrapping, as it is in xmlenc-core), or otherwise would it
probably be just informational?

Paul

On Mon, 2011-07-25 at 10:21 -0400, Richard L. Barnes wrote:

> <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
> 
> _______________________________________________
> woes mailing list
> woes@ietf.org
> https://www.ietf.org/mailman/listinfo/woes