[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enum] Review of draft-yu-enumservice-sms-smpp
Alex,
Thanks for the comments. Please see the responses below that begin
with [YU].
James
-----Original Message-----
From: Alexander Mayrhofer [mailto:alexander.mayrhofer at enum.at]
Sent: Wednesday, April 23, 2008 11:40 AM
To: Yu, James; enum at ietf.org
Subject: Review of draft-yu-enumservice-sms-smpp
Hello Yu,
i spent some time on reviewing your sms:smpp draft - i have a couple of
comments (i probably missed some details, but given the early stage of
the draft, i guess we'll go through more reviewing anyway..)
I like the idea, i understand that it makes sense. However, i don't
think this is neccessarily limited to private use... For example, we're
running our own SMPP server for the number range +4359966, and i don't
see why i wouldn't publish a corresponding ENUM record even in User ENUM
... (we're limiting access on the SMPP layer, of course).
There are some minor things, but also some major content issues, i've
listed them in the order i noticed them...
- Title: I'd recommend moving the "RFC 4355" part to the block on top of
the draft, so that it says "Updates: RFC 4355 (if approved)". I'd also
change the title into "IANA registration of the 'smpp' URI scheme and
the 'smpp' subtype for the 'sms' Enumservice" (or the other way round,
mentioning the Enumservice first)
[YU] The title is changed to - IANA Registrations of Enumservice
"sms:smpp" and "smpp" URI
- The draft does not have proper page breaks.
[YU] Will check.
- Maybe you could merge "Conventions" and "Abbreviations" into a
"Terminology" section, and put it in front of the Introdcution, which
would save you expanding all the terms in the intro.
[YU] "Abbreviations" section will become section 2.
- There should be an informative reference to X.25
[YU] Will add.
- The ABNF reference is outdated in the text (2234), but ok in the
references (RFC 5234)
[YU] Will correct.
- Section 5 ("use of..") is not just about the URI scheme, also about
the Enumservice. Maybe just rename that to "Use Cases" or "Use Case
Examples". Disclaimer: I didn't go thorugh the use cases themselves
because i'm not that deep into SMS delivery :-)
[YU] Will change to "Use Cases".
- I'm missing a description of the dereference process of an "smpp" URI.
For example: What is the exact process of determining the final (IP
level) destination (and port) from an "hostpart":
- Does it make use of NAPTR lookups, or SRV lookups?
- What is the default port, if not defined?
- How can one specify a port? in the "hostpart"?
The "hostpart" that you say is "imported from RFC 3261" is not specified
in 3261... it occurs once in the text, but is never specified...
[YU] In Section 6, SRV RR lookup is added in the example. The default
port for SMPP is 2775. "hostpart" should be "hostport".
In addition, the "telephone-subscriber" that you import into the "user"
part already allows parameters (namely, all "tel" URI parameters, so you
do essentially allow _two_ sets of parameters, like
smpp:+4359966;cic=+1-6789;npdi at smpp.example.com;parameterXY=bla
Does that make sense, and is this intended? If it is intended, what are
the semantics of the "user" parameters... I'm unsure whether this is
actually allowed by the URI ABNF itself...
[YU] Will define "user" parameter.
- Would it be possible to make note of the "Application Class" subtype
in the Enumservice Registration itself? i think it would be a "Common
Application" Enumservice as in 4.2.4 of the Enumservice guide draft..
[YU] Will change to "Common Application".
- The column (":") is not part of the URI scheme name. Please remove it
from the URI scheme part of the registration template.
[YU] Will remove ":".
- I'm not happy with the last sentence of the "security considerations"
section of the Enumservice template (limiting access to the DNS). I
think that might also trigger a lot of headwind from the DNS guys. It's
actually an implementation veriant in certain scenarios, but i don't see
why that would need to be included in the registration template.
[YU] Will remove.
- The URI scheme needs improvement. As mentioned above, i can't find the
"hostpart" definition, the "telephone-subscriber" import adds parameter
space with unclear semantics, and i'm missing clear dereferencing
instructions.
[YU] Will improve.
- If you define parameters for the SMPP URI, you will probably need to
define a registry for them (remember what happened to the tel: URI -
they needed to add a registry in a seperate document
http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-05.txt)
[YU] Will write a separate I-D.
- References: I think a couple of references can be moved to informative
status.
[YU] Will move some.
hope that helps!
cheers
Alex
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum