Re: New Version Notification for draft-nottingham-link-hint-00.txt

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