Subject: [weirds] links

From: Ernie Dainow <[email-masked]>
Date: Fri, 15 Mar 2013 16:32:39 -0400

I found the use of links rather unclear in
draft-ietf-weirds-json-response-02. While the syntax and basic concept are
well explained, some guidance as to when to use links and what relationship
type should be used would be helpful.

Most of the examples are of relationship "self". If a client follows such a
link, it seems it will get back mostly information that it already has (in
the examples). So what is the value of this type of link? I think this type
of link should be "rel: alternate", so that a client does not waste time
getting duplicate information.

A useful guideline would be to use a "self" link where an object has been
returned with only its handle (such as in an entity) and not much else. In
this case a client knows it can follow the link to get the details of the
object.

One interesting link is shown in section 10.
 "value" : "http://example.net/ip/2001:db8::/48",
 "rel" : "up",
 "href" : "http://example.net/ip/2001:C00::/23"
Presumably this is a link to get the parent network. What is the
recommended way to get child networks? The IANA list does not include
anything like "down" or "child"
http://www.iana.org/assignments/link-relations/link-relations.xml

What about the set of relations: first, last, previous, next? Would one
expect these to be provided for the IP Network object, or any other RDAP
objects?

It might be best for people working on client implementations to suggest
links they would expect or like to see. If clear guidelines are not
provided, it really won't be clear to a client what it should do with a
link, especially if different server implementations have a different
interpretation of what the different relationships mean in the RDAP context.

-Ernie

---

From: Franck Martin <[email-masked]>
Date: Fri, 15 Mar 2013 20:42:51 +0000

Too much to read so allow me to shortcut to find my ways...

I think the WG charter limits the protocol to http, but have you considered something like http://abusix.org/service/abuse-contact-db
For a mail server DNS is more natural than http. Knowing in a query how old is the domain name, who is the registrar, registrant and what is the email address for abuse would I think help in an email reputation system/email reporting system.

Which document defines the list of fields and their format? Or os it out of scope? I don't mean which fields are mandatory, but if want to report when the domain was registered, what field should I use and what format?

Thanks.

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 15 Mar 2013 20:53:45 -0400

I'm afraid we're a bit to far off in the work of the WG to consider that.

Besides, IMO, I really don't think that putting all kinds of information
into the DNS is such a great idea.

People also can create their DNS <-> RDAP proxies if they really, really
want to.

s2,

~Carlos

On 3/15/13 4:42 PM, Franck Martin wrote:
> I think the WG charter limits the protocol to http, but have you
> considered something like http://abusix.org/service/abuse-contact-db
> For a mail server DNS is more natural than http. Knowing in a query how
> old is the domain name, who is the registrar, registrant and what is the
> email address for abuse would I think help in an email reputation
> system/email reporting system.
> 
> Which document defines the list of fields and their format? Or os it out
> of scope? I don't mean which fields are mandatory, but if want to report
> when the domain was registered, what field should I use and what format?
> 
> Thanks.
> 
> 
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 16 Mar 2013 09:48:39 -0400

I'm fairly sure RDAP supports responses that include those fields.  HTTP is
more heavyweight than DNS, of course, but replies are cacheable.  The work
of the REPUTE WG has resulted in extensions to mail servers that use HTTP
and they haven't been a huge problem, though admittedly I don't think it's
been tried at large scales yet.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 16 Mar 2013 19:08:48 -0000

>> For a mail server DNS is more natural than http.

abuse.net does the same thing, look up example.com.contacts.abuse.net
and my funky DNS server will give you TXT records with the contact
addresses and HINFO to say where they came from.

But I think this sort of thing would be a severely premature
optimization for WEIRDS.  Both abuse.net and abusix return very simple
results, little more than a list of e-mail addresses, while WEIRDS
returns all the junk in a WHOIS record.  If we deploy this and find
performance bottlenecks in practice, we can consider add-ons to return
whatever the critical subset is more efficiently.

People in a hurry might also look at the CORE working group, which
stands for Constrained Restful Environments.  They're defining a
scheme called COAP which is intended to run over UDP and be so
lightweight that it can be implemented in things like light switches.

http://tools.ietf.org/id/draft-ietf-core-coap-14.txt

Again, this might make sense as a followon, not a replacement for
the existing http design.

---

From: Andy Newton <[email-masked]>
Date: Sun, 17 Mar 2013 14:48:14 +0000

Ernie,

My responses in-line:

From:  Ernie Dainow <[email-masked]>
>draft-ietf-weirds-json-response-02. While the syntax and basic concept
>are well explained, some guidance as to when to use links and what
>relationship type should be used would be helpful.

I agree. We should beef this up.

>
>Most of the examples are of relationship "self". If a client follows such
>a link, it seems it will get back mostly information that it already has
>(in the examples). So what is the value of this type of link? I think
>this type of link should be "rel: alternate",
> so that a client does not waste time getting duplicate information.

The value of the "self" link is so to formally give the restful url to
that object. This is helpful for clients that wish to do smart caching of
embedded objects, such as entity objects inside a domain or network object.

>returned with only its handle (such as in an entity) and not much else.
>In this case a client knows it can follow the link to get the details of
>the object.

I think we should use the RECOMMENDED 2119 language to encourage the use
of self links whenever possible. Does that sound like a good idea?

>http://www.iana.org/assignments/link-relations/link-relations.xml

I guess that would result in multiple "child" links. Perhaps we ought to
see about registering that relationship. Maybe "down" and not "child".

>expect these to be provided for the IP Network object, or any other RDAP

I don't think these are applicable to much in the RDAP sphere.

>link, especially if different server implementations
> have a different interpretation of what the different relationships mean
>in the RDAP context.

Very good points. If there are no objections, I'll seek to clarify the
usage. The "self" might go into the actual section on links for a
normative RECOMMENDED and the other relationships in an appendix.

Thanks for the questions, Ernie.

-andy

---

From: Behnam Esfahbod <[email-masked]>
Date: Sun, 17 Mar 2013 16:55:13 -0400

Hi,

Looking at the "links" attribute, I also couldn't figure it out whether
these "links" are talking about the (ip address, domain name, name server,
etc) *objects* themselves or about the WEIRDS *document*. An "up"
relationship could be defined very different for each of them.

Also, there are serious problems with the level or localization support.
Besides the contact information, which will be changed to practice JCARD
outpus, it looks like the structure of the objects are designed to only
match some specific implementations. Here are a few of these problems:

* Attribute "hreflang" is an array, but the semantics of the array is
unknown.

* Attribute "title" is an array, but the semantics of the array is unknown.
Are these titles suppose to match languages mentioned in "hreflang"?!

* And there was a discussion about attribute "discussion", and as mentioned
in the WG meeting, there is no need to reinvent HTML again. If there's a
need for any formatting, let's RECOMMEND an existing one and not create a
new one.

To make it short, we have a lot of human-readable strings in this APP
protocol and IMHO it's exhausting to deal with languages in the
lowest-level attributes. Maybe the multipart-MIME approach would be better,
with some "links" to other available languages.

So, I think the question to answer would be: "Do we want the WEIRDS
response be as complete as possible, or targeted for an specific local
(language, region, etc)?" I'm not sure if this matter has been discussed
already or not.

Thanks,
-Behnam

On Fri, Mar 15, 2013 at 4:32 PM, Ernie Dainow <[email-masked]> wrote:

> (in the examples). So what is the value of this type of link? I think this
> type of link should be "rel: alternate", so that a client does not waste
> time getting duplicate information.
>

-- 
Behnam Esfahbod | بهنام اسفهبد
http://behnam.es/
GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B

---

From: Andy Newton <[email-masked]>
Date: Mon, 18 Mar 2013 14:50:10 +0000

Behnam,

In-line againŠ :)

From:  Behnam Esfahbod <[email-masked]>
>these "links" are talking about the (ip address, domain name, name
>server, etc)
>objects themselves or about the WEIRDS document. An "up" relationship
>could be defined very different for each of them.

I'm not sure what you mean about "the WEIRDS document". But the opening
sentence in that section says, "Each object class defined in this document
may have links to other resources on the Internet." The links are for each
type of object. Obviously, "up" does not apply to everything, such as an
entity.

>* Attribute "title" is an array, but the semantics of the array is
>unknown. Are these titles suppose to match languages mentioned in
>"hreflang"?!

Those are taken from RFC5988. I don't think we should start redefining
link relationships. If it wasn't properly internationalized, then that is
an issue for the IESG to consider.

>lowest-level attributes. Maybe the multipart-MIME approach would be
>better, with some "links" to other available
> languages.
>

Yes, we have discussed this and the result was the addition of the JSON
'lang' attribute. See section 5.3 of the JSON response draft.

-andy