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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: RE: [saml-dev] Encoding of URI in "Alternative SAML Artifact Form at"

Hi Yuji, Juergen:

You have pointed out a missing piece in the non-normative
"Alternative Format" in the binding doc. 

Would it be adequate to specify UTF-8 as the 
default charset to be used here?

- prateek

>>> chapter 9 of the Bindings document introduces an 
>>alternative format for the
>>>  Assertion Artifact:
>>> TypeCode          := 0x0002
>>> RemainingArtifact := AssertionHandle SourceLocation
>>> AssertionHandle   := 20-byte_sequence
>>> SourceLocation    := URI
>>> To create the artifact, Base64 is to be applied to the 
>>concatenation of 
>>> TypeCode and RemainingArtifact.
>>> Base64 uses Bytes as input.
>>> The specification does not specify how to convert the 
>>character-like URI 
>>> into bytes. 
>>The following resources may be helpful for you
>>2.1 URI and non-ASCII characters
>>I also agree that SourceLocation's URI should  require a 
>>single charset, 
>>define a default charset, or provide a way to indicate the  
>>charset used.
>>NTT Data Corporation
>>Yuji Sakata
>>Tel: +81-3-3523-8081
>>E-Mail: sakatayu@nttdata.co.jp
>> RFC 22396 :: 2.1 URI and non-ASCII characters
>>   The relationship between URI and characters has been a source of
>>   confusion for characters that are not part of US-ASCII. To describe
>>   the relationship, it is useful to distinguish between a "character"
>>   (as a distinguishable semantic entity) and an "octet" (an 8-bit
>>   byte). There are two mappings, one from URI characters to 
>>octets, and
>>   a second from octets to original characters:
>>   URI character sequence->octet sequence->original character sequence
>>   A URI is represented as a sequence of characters, not as a sequence
>>   of octets. That is because URI might be "transported" by means that
>>   are not through a computer network, e.g., printed on 
>>paper, read over
>>   the radio, etc.
>>   A URI scheme may define a mapping from URI characters to octets;
>>   whether this is done depends on the scheme. Commonly, within a
>>   delimited component of a URI, a sequence of characters may 
>>be used to
>>   represent a sequence of octets. For example, the character "a"
>>   represents the octet 97 (decimal), while the character 
>>sequence "%",
>>   "0", "a" represents the octet 10 (decimal).
>>   There is a second translation for some resources: the sequence of
>>   octets defined by a component of the URI is subsequently used to
>>   represent a sequence of characters. A 'charset' defines 
>>this mapping.
>>   There are many charsets in use in Internet protocols. For example,
>>   UTF-8 [UTF-8] defines a mapping from sequences of octets 
>>to sequences
>>   of characters in the repertoire of ISO 10646.
>>   In the simplest case, the original character sequence contains only
>>   characters that are defined in US-ASCII, and the two levels of
>>   mapping are simple and easily invertible: each 'original character'
>>   is represented as the octet for the US-ASCII code for it, which is,
>>   in turn, represented as either the US-ASCII character, or else the
>>   "%" escape sequence for that octet.
>>   For original character sequences that contain non-ASCII characters,
>>   however, the situation is more difficult. Internet protocols that
>>   transmit octet sequences intended to represent character sequences
>>   are expected to provide some way of identifying the 
>>charset used, if
>>   there might be more than one [RFC2277].  However, there is 
>>   no provision within the generic URI syntax to accomplish this
>>   identification. An individual URI scheme may require a single
>>   charset, define a default charset, or provide a way to indicate the
>>   charset used.
>>   It is expected that a systematic treatment of character encoding
>>   within URI will be developed as a future modification of this
>>   specification.
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC