Subject: [Enum] requesting feedback on XMPP specific issues...

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 08 Nov 2006 00:48:29 +0100

Hi,

as mentioned in the session, i've discovered two "special" issues with XMPP
URIs/IRIs when being used in ENUM. I'd appreciate feedback on this, as i'm
currently preparing the next draft revision.

1) Authentication component:

XMPP URIs may contain an authentication component, which instructs the
client to authenticate as the user id given in the URI, and then contact a
differen user id, eg.

xmpp://[email-masked]/[email-masked]

would instruct the client to authenticate as "[email-masked]", and then
contact "[email-masked]".

I have now text in the draft that the output URI of this Enumservice SHOULD
NOT contain such an authentication component - there might be corner cases
where it could be useful, so i refrained from using MUST.

2) IRIs:

XMPP supports IRIs (non-ASCII characters in the URI). However, non-ASCII
characters are always "percent-encoded", so the replacement part of the
regex string in the NAPTR should always contain ASCII only. However, the
regex algorithm _could_ be affected...

I have currently no text about this issue in the draft. I have a strong
opinion against disallowing IRIs in this Enumservice, because if XMPP itself
supports them, a restriction here would limit the applicability of the
Enumservice to a subset of the potential users. (And, the XMPP clients which
support this Enumservice will need to support IRIs anyway to be compliant to
the XMPP URI spec).

However, do we need some text about special considerations with regards to that?

I'd appreciate comments (or even text!) about those issues.

thanks,

Alex

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 08 Nov 2006 14:07:37 -0800

> where it could be useful, so i refrained from using MUST.

What about just mentioning that issue in the Security Considerations
section? I don't think we're in a position to issue SHOULD NOTs or MUST 
NOTs for this subject: I think it's good enough to make the reader aware
that URIs can contain authentication data. After all, the same issue 
applies to http: and ftp: URIs as well. RFC4002 does not touch upon this 
at all.

> However, do we need some text about special considerations with regards to that?

My approach here is that we need to clarify that the DDDS algorithm with
its regexp evaluation happens before any IRI unescaping. In other words,
the output of the ENUM algorithm is always an ASCII-encoded string.

Whether that string is in fact an encoded IRI should not concern us.
The ENUM client code (especially the regexp parts) need not be UTF-8 aware.

/ol

---

From: "JoonHyung Lim" <[email-masked]>
Date: Thu, 9 Nov 2006 02:40:34 -0800

Basically, I also agree with this feedback now.

I'm not compleletly sure that authentication component is not needed in XMPP
enumservice in any case, and intended status of this document is
"informational".

For IRIs matter, I have similar case in Korea during the User ENUM trial.

To use the Korean characters describing geographical location information in
ENUM, we encoded the Korean character with base64 encoding method, and put
it into the NAPTR RR. but, ENUM-aware client doesn't have to care about a
any encoded data when it try to find a data, because ENUM-aware client just
brings the data to another application that can decode the data to use. Even
if there is "percent-encoding", I think disallowing the IRIs is unnecessary.

JoonHyung Lim

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Wednesday, November 08, 2006 2:08 PM
> To: Alexander Mayrhofer
> Cc: [email-masked]
> Subject: Re: [Enum] requesting feedback on XMPP specific issues...
> 
> > client to authenticate as the user id given in the URI, and then 
> > contact a differen user id, eg.
> > 
> > I have now text in the draft that the output URI of this 
> Enumservice 
> > SHOULD NOT contain such an authentication component - there 
> might be 
> > corner cases where it could be useful, so i refrained from 
> using MUST.
> 
> What about just mentioning that issue in the Security 
> Considerations section? I don't think we're in a position to 
> issue SHOULD NOTs or MUST NOTs for this subject: I think it's 
> good enough to make the reader aware that URIs can contain 
> authentication data. After all, the same issue applies to 
> http: and ftp: URIs as well. RFC4002 does not touch upon this at all.
> 
> > 2) IRIs:
> > 
> > XMPP supports IRIs (non-ASCII characters in the URI). However, 
> > non-ASCII characters are always "percent-encoded", so the 
> replacement 
> > part of the regex string in the NAPTR should always contain ASCII 
> > only. However, the regex algorithm _could_ be affected...
> > 
> > I have currently no text about this issue in the draft. I have a 
> > strong opinion against disallowing IRIs in this 
> Enumservice, because 
> > if XMPP itself supports them, a restriction here would limit the 
> > applicability of the Enumservice to a subset of the 
> potential users. 
> > (And, the XMPP clients which support this Enumservice will need to 
> > support IRIs anyway to be compliant to the XMPP URI spec).
> > 
> My approach here is that we need to clarify that the DDDS 
> algorithm with its regexp evaluation happens before any IRI 
> unescaping. In other words, the output of the ENUM algorithm 
> is always an ASCII-encoded string.
>

---

From: lconroy <[email-masked]>
Date: Thu, 9 Nov 2006 11:26:43 +0000

Hi there folks,
  Did I miss something on the XMPP Enumservice specification?

An Enumservice registration can't be Informational (I know - I argued
that this clause was not needed when 3761 was being written).

 From RFC 3761:
3.1.4.  Publication Requirements

    Proposals for Enumservices registrations MUST be published as one of
    the following documents; RFC on the Standards Track, Experimental
    RFC, or as a BCP.

Informational is notably missing from this list.

all the best,
   Lawrence

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 09 Nov 2006 22:24:16 +0100

> that this clause was not needed when 3761 was being written).

That is an error in the document, of course. Sorry for the confusion.

Alex

---

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 09 Nov 2006 22:28:32 +0100

> if there is "percent-encoding", I think disallowing the IRIs is unnecessary.

Well, at least for IRIs, there is a standardized procedure to map them to
URIs. It is outlined in Section 3.1 of RFC 3987. I will have text in the
next revision of the draft that this procedure should be followed when using
IRIs with ENUM.

But: It seems to be rather "hacky" to use base64 for encoding of URIs in
ENUM, unless the URI is a "data" URI, which actually supports base64
encoding afaik.

Alex

---

From: lconroy <[email-masked]>
Date: Fri, 10 Nov 2006 00:43:33 +0000

Hi Folks,
  See section 3.1 of draft-ietf-experiences-04.txt. Bottom of page 7  
et.seq.
(Been there, seen it, done it :).
Using the IRI to URI conversion rules is a MUST, not a SHOULD, or you  
will break
perfectly valid conforming client programs.

Agree - If this is in a NAPTR, then it generates a URI, No? The only  
legal choice
if you MUST use an E2U NAPTR is to put the "stuff" inside a data: URI.

Why not use a TXT record? That takes multiple strings, each of which  
can contain
up to 255 octets of binary data - TXT looks like it will work fine  
for your needs.

Note - IRIs are *not* permitted in 3761 as specified - only URIs.
Just a block of Base64 encoded data instead of a URI is certainly not  
permitted.

Bad things may happen to a valid conforming ENUM client if it hits  
this "NAPTR".
(At least use an experimental Enumservice (X-xxxx) to tell foreign  
clients to
ignore these NAPTRs).

all the best,
   Lawrence