Subject: [domainrep] XML vs. JSON examples

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Apr 2012 07:02:33 +0000

Tony requested in Paris that I post examples of the repute query, one with XML and one with JSON.  Here they are (attached) from my own application.

I'm planning to post a new version of the media-type and query-http documents with all the suggested changes, including this one, by the end of the week.

-MSK

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 04 Apr 2012 13:25:40 +0300

Hi Murrary, 

Wouldn't you have to also add the namespace declaration to the XML instance
document, namely

<?xml version="1.0" encoding="UTF-8"?>
   <reputation
     xmlns="urn:ietf:params:xml:ns:reputation">

Wouldn't the content type be
* application/json ( for JSON)
* application/reputation+xml (for XML)

Ciao
Hannes

On 4/4/12 10:02 AM, "Murray Kucherawy" <[email-masked]> wrote:

> Tony requested in Paris that I post examples of the repute query, one with XML
> and one with JSON.  Here they are (attached) from my own application.
>  
> I¹m planning to post a new version of the media-type and query-http documents
> with all the suggested changes, including this one, by the end of the week.
>  
> -MSK
> 
> 
> _______________________________________________
> domainrep mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/domainrep

---

From: Tony Hansen <[email-masked]>
Date: Wed, 04 Apr 2012 09:10:41 -0400

Thank you Murray.

As expected, the differences are mostly cosmetic. I think the layering 
you used for extensions with json are cleaner than your example in xml, 
which might actually indicate a problem with the way the xml is laid out.

Should there be an outer key-value indicator that this is a reputon, as in

     { "reputon" : {
         "rater" : "repute.opendkim.org",
         ....
?

I'm supportive of switching the document over to using json.

I think the content types should be application/reputon+json instead of 
application/reputon. (And application/reputon+xml if we somehow wind up 
with the xml version instead.)

     Tony

On 4/4/2012 3:02 AM, Murray S. Kucherawy wrote:
>
> Tony requested in Paris that I post examples of the repute query, one 
> with XML and one with JSON.  Here they are (attached) from my own 
> application.
>
> I'm planning to post a new version of the media-type and query-http 
> documents with all the suggested changes, including this one, by the 
> end of the week.
>
>

---

From: Douglas Otis <[email-masked]>
Date: Wed, 04 Apr 2012 10:52:50 -0700

On 4/4/12 6:10 AM, Tony Hansen wrote:
> you used for extensions with json are cleaner than your example in 
> xml, which might actually indicate a problem with the way the xml is 
> laid out.
>
> I think the content types should be application/reputon+json instead 
> of application/reputon. (And application/reputon+xml if we somehow 
> wind up with the xml version instead.)

Dear Tony,

Disagree.  XML showing a 50% increase is more than cosmetic (without 
including templates).  Similar considerations were made in the CoRE 
protocol that even extended to HTTP components.  Low level services (not 
intended for direct human consumption) should consider the merits of 
resource conservation with the benefit of retaining suitability in 
different environments.  Support of jason is welcome, but is there a 
real need to consider the format optional with addition of reputon+json 
instead of just reputon?

Regards,
Douglas Otis

---

From: Dave Crocker <[email-masked]>
Date: Wed, 04 Apr 2012 07:03:33 -0700

On 4/4/2012 6:10 AM, Tony Hansen wrote:
> application/reputon. (And application/reputon+xml if we somehow wind up with the
> xml version instead.)

The latter naming template convention (+xml) is well-established.

Even if an equivalent convention has not yet been established for json, it makes 
sense to reapply the model for naming json-based media-types.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Apr 2012 18:27:39 +0000

Since all of the outer containers in the reply would be reputons, isn't it redundant to actually say that?  Or is the point to be sure, just in case you happen to be talking to the wrong service somehow?

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Hansen
Sent: Wednesday, April 04, 2012 6:11 AM
Cc: [email-masked]
Subject: Re: [domainrep] XML vs. JSON examples

Thank you Murray.

As expected, the differences are mostly cosmetic. I think the layering you used for extensions with json are cleaner than your example in xml, which might actually indicate a problem with the way the xml is laid out.

    { "reputon" : {

I think the content types should be application/reputon+json instead of application/reputon. (And application/reputon+xml if we somehow wind up with the xml version instead.)

    Tony

---

From: Tony Hansen <[email-masked]>
Date: Wed, 04 Apr 2012 18:32:38 -0400

On 4/4/2012 10:02 AM, Dave Crocker wrote:
> Even if an equivalent convention has not yet been established for 
> json, it makes sense to reapply the model for naming json-based 
> media-types.

Although draft-ietf-appsawg-media-type-regs both mentions the use of 
+json and defines a registry that can be used to register it, and 
despite +json being used already in a variety of registered media types, 
+json hasn't been formally defined yet.

So, I posted draft-hansen-media-type-suffix-regs-00 for consideration to 
fill in this hole.

Discussion of the draft should occur on the APPS AWG mailing list 
<[email-masked]>.

     Tony Hansen
     [email-masked]

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 05 Apr 2012 01:06:06 +0200

>So, I posted draft-hansen-media-type-suffix-regs-00 for consideration to 

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04304.html
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ned Freed <[email-masked]>
Date: Wed, 04 Apr 2012 16:38:06 -0700 (PDT)

> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04304.html

It someone wants to do this registration in an RFC, I have no objection - 
as long as the RFC in question isn't the registration document itself.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Wed, 04 Apr 2012 23:44:11 -0400

Hmmm, interesting. Even though I'm a co-author on that doc, I forgot 
about that particular tidbit in it. :-)

I still think it's worth separating out the registration of these 
suffixes and making them explicit.

     Tony Hansen

---

From: Roland Turner <[email-masked]>
Date: Thu, 05 Apr 2012 12:22:19 +0800

+1

---

From: Ned Freed <[email-masked]>
Date: Wed, 04 Apr 2012 16:53:37 -0700 (PDT)

> So, I posted draft-hansen-media-type-suffix-regs-00 for consideration to

The draft looks good to me. The one question I have is whether or not we also
want to register +ber for Basic Encoding Rules. +der is actually a subset of
+ber, but while some types require use of DER, there are probably some that do
not, and using +der for those would be incorrect. And either one can be
processed to some extend without the ASN.1 schema.

The latter point is why it doesn't make sense to register +per for Packed
Encoding Rules. PER cannot be processed without knowing the ASN.1 schema
involved, because what's in the schema changes the representation on the wire.

I've also never heard of any actual use of PER or Canonical Encoding Rules
(CER), so I see no reason to bother with either. Which is a pity, because I
like CER a lot more than DER.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 05 Apr 2012 04:33:16 -0700

On 4/4/2012 11:27 AM, Murray S. Kucherawy wrote:
> Since all of the outer containers in the reply would be reputons, isn’t it
> redundant to actually say that?  Or is the point to be sure, just in case you
> happen to be talking to the wrong service somehow?

standalone self-identification is usually much better than relying on context to 
define things.  Your second sentence is a good example of the reason.

d/
-- 

   Dave Crocker