OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [bdxr] Initial survey of use cases for a discovery/location service for interaction/collaboration metadata retrieval.



Thanks again for putting together this document.  As we discussed briefly on the call, it seems to me quite problematic if our representation of an email address in this system required the cooperation of the domain owner.  It seems very implausible that gmail.com etc would make any changes whatsoever to conform to our requirements!


The basic issue we face here, I think, is how to avoid potential collisions between the representations of potentially valid domain names, and email addresses for lookup purposes.  Since we’re talking about a URN here, rather than a URL, the underlying question seems to me whether there is any character (“@” ideally, but not necessarily) that we could use in a URN that would be disallowed in a URL so as to create a clean separation.


In your document, you do say “Supposedly any binary octet string is allowed as a label (RFC 2181, section 11).  But for TLDs, the working rule has been case-independent “letters/digits/hyphens” in labels.  RFCs do specify DNS labels using octets other than letters/digits/hyphens”.  But surely it’s not actually possible to register a domain name that includes the @ character (in particular), since that would break the email system?  So there must be some restrictions.


Perhaps you could clarify the issue and constraints here as you see them – or if there’s any issue as to the use case here that I can clarify.  I’ll forward to the BDXR list one or two previous emails on this.





From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Moberg Dale
Sent: Monday, June 25, 2012 8:49 AM
To: bdxr@lists.oasis-open.org
Subject: [bdxr] Initial survey of use cases for a discovery/location service for interaction/collaboration metadata retrieval.


In the attached document,  I have provided some “use cases” that make use of defined (and implemented) capabilities of the DNS in order to find out about a person or organization’s  interaction/collaboration capabilities (including endpoint information).


The use cases are annotated with hints about how the Dynamic Delegation Discovery Service [DDDS  -- Dynamic Delegation Discovery Service, whose core parts are specified in five RFCs 3401 through 3405] could be used in building a DDDS application -- the sequence of processing steps involved when using several DNS queries to produce a desired discovery result.


Defining a (reasonably simple but complete) DDDS application allows us to generalize the discovery/location aspects of PEPPOL to apply to a much wider range of interactions, and to support a much wider range of security options.


Specific DDDS applications are found in VOIP, SIP, ONS, FONS and several other specifications.


Also I have included a brief terminology section that we can add to the wiki. More additions will be needed.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]