Loading ...
Sorry, an error occurred while loading the content.

19479Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt

Expand Messages
  • Mark Nottingham
    Jun 25, 2013
      Please have a look at the draft; the level of detail in the registrations is "a number" or "a list" or (infrequently) "an object" -- roughly on par with saying that a field in a registry is "an integer," which is quite common in IANA-land.


      On 25/06/2013, at 7:36 PM, Stephen Farrell <stephen.farrell@...> wrote:

      > Just had a a quick peek at this since we've seen a case where stuff went wrong because a registry contained structured data. Roughly: 1) can we have an early allocation to work with IEEE; 2) oops that bit there should've been a 1; 3) can we mark (1) as reserved and redo stuff?
      >
      > I think it's a mistake to ask IANA to handle structured data of any sort and this does that in spades.
      >
      > As a question: what makes you think this wouldn't be very likely to result in erroneous registrations? (Damaging the effectiveness of this registry but also possibly the IANA function, a bit)
      >
      > S
      >
      >
      > On 25 Jun 2013, at 05:17, Mark Nottingham <mnot@...> wrote:
      >
      >> Hi Erik,
      >>
      >> Sorry for the delay - just back home now.
      >>
      >>> but i have one question about the general registry model: the current draft says that hints MUST have a name (very reasonable, of course), but also that hints MUST have their data model being defined in JSON.
      >>>
      >>> http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1
      >>>
      >>> living in a world where we have JSON services, XML services, and RDF services, it seems that hard-coding a specific language data model into such a spec (without constraining it in any way) will limit the utility of such a registry.
      >>
      >> It needs *a* data model.
      >>
      >>> for example, in the Home Document draft, which is the original source of the link hint idea, the hints were hard-coded with very constrained data models. this made it relatively easy to expose them in a different syntax (in the XML Home Document draft):
      >>>
      >>> http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4
      >>>
      >>> without getting too much into the details of this specific registry: what are the best practices about allowing/controlling language dependencies in registries?
      >>
      >> Whoa, hold on - who said anything about a language? This is just the underlying data model; you can express it in a document however makes sense.
      >>
      >>> personally, i would feel more comfortable with having a registry that is of equal value to people regardless of their implementation language
      >>
      >> You're using "language" quite loosely here.
      >>
      >>> , but then again that means that the registry itself must define a "mini-language" of its own.
      >>
      >> -1. Defining Yet Another Data Model as a political solution to avoid picking an existing one is sub-optimal at best.
      >>
      >> Cheers,
      >>
      >>
      >> --
      >> Mark Nottingham http://www.mnot.net/
      >>
      >>
      >>
      >> _______________________________________________
      >> apps-discuss mailing list
      >> apps-discuss@...
      >> https://www.ietf.org/mailman/listinfo/apps-discuss

      --
      Mark Nottingham http://www.mnot.net/
    • Show all 12 messages in this topic