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

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@cs.tcd.ie> 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@mnot.net> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/