On 05/08/2008 5:13 PM, Danny Ayers wrote: > 2008/5/8 Peter Saint-Andre <stpeter@xxxxxxxxxx>: > >> In the Jabber community we've been looking at defining links to, say, a >> chat room where a post could be discussed. Therefore we've been thinking >> about defining rel="discuss". The value of such a link could point to an >> XMPP-based or SIP-based groupchat room, an IRC channel, an email >> discussion list, a web forum, or other such venue. Does this seem >> reasonable? > > > Pretty much : "discuss" seems a good umbrella term, I'd imagine it being a > better choice than say "chat" or "comment". > > Might there be any constraints on/expectations about what it *could* point > to? My expectation is that a link of rel="discuss" will point to a venue where multiple individuals can exchange textual messages about the post (or the topic covered by the post). If someone tried to extend this model to voice or video conferences, I might not object; but I think we might want to define a different relation for that kind of rich-media interaction. > Also noting the spec: > [[ > The value of "rel" MUST be a string that is non-empty and matches > either the "isegment-nz-nc" or the "IRI" production in [RFC3987]. > ]] > http://tools.ietf.org/html/rfc4287#page-21 > 4.2.7.2. Sure, those are not a problem. Philosophical discussion follows... > Is there any advantage in it being a registered string, as opposed to a > (HTTP dereferenceable) IRI? I like registries. :) Plus I have seen no one else define a link relation that is an IRI. But the choice is not either-or -- couldn't you define a value of "rel" that is an IRI yet is still registered? > Apart from minor syntax convenience, I can only really see disadvantages in > the shortstring+registry approach - an extra level of indirection, So you type "atom link relation alternate" in your favorite search engine, or visit the IANA registry page. I don't see any deep disadvantages here. > the > political stuff, Sure, all standardization processes involve politics. However, the registration procedures defined in RFC 4287 and RFC 2434 don't seem very onerous to me. I'd prefer something like the procedures in RFC 3864, but I didn't pay enough attention to the atom format I-D before it became an RFC, so I don't have grounds for complaining. > latency if things need changing. Sometimes latency is a good thing. Among other things it can force you define things properly the first time around. > With a HTTP URI and > appropriate Web representation, it's one step and in your hands. Yeah, I've > heard arguments why some level of centralization is desirable for some > things, but for keywords like this I'm not convinced...only my 0.02 euro. /me shrugs I understand your concerns, but IMHO the horses are out of the barn here, since RFC 4287 is already published. I work within the structures I've been given. :) Peter -- Peter Saint-Andre https://stpeter.im/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature