Re: New Version Notification for draft-nottingham-link-hint-00.txt
Mark Nottingham <[email protected]> Tue, 25 Jun 2013 19:46:10 +1000
| Newsgroups | gmane.ietf.apps-discuss,gmane.comp.web.services.rest |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/